feat: Cleanup to shrink smallest program size#2389
Open
spotandjake wants to merge 1 commit intograin-lang:oscar/gc-rebasedfrom
Open
feat: Cleanup to shrink smallest program size#2389spotandjake wants to merge 1 commit intograin-lang:oscar/gc-rebasedfrom
spotandjake wants to merge 1 commit intograin-lang:oscar/gc-rebasedfrom
Conversation
This is a rather small pr, I was looking through the binary of our smallest program and noticed a few things that were being left behind. Not very important but we can save a few bytes by removing the unnecessary function wrapping our exception setup, this function was required when exception handling was unsafe however it's now completely safe so there is no reason to map it. The bigger change is I noticed that `bigIntToString` was doing some weird things, firstly the `_SIZES` array wasn't actually ever being used however it was causing the function to require a closure which was being setup in every program and adding a rather substantial amount of size. Secondly because we had a helper function that used`_DIGITS` inside of the toString method this created a closure and because we were not lazily initializing digits this was adding quite a few bytes to the program, with a few simple changes this cuts program size and I tracked length along with the result buffer when stringifying which saves an iteration over the result buffer, and the corresponding helper.
spotandjake
requested review from
alex-snezhko,
marcusroberts,
ospencer,
peblair and
phated
as code owners
ospencer
reviewed
May 3, 2026
Member
ospencer
left a comment
ospencer
left a comment
There was a problem hiding this comment.
It seems like we should have a new test for that small bug fix in the bigint printing.
Member
Author
There wasn't really a bug just closures causing the code to get included. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I wasn't sure if this was a
featorchore. I was looking through the binary of our smallest program, and noticed that a few uneccessairy functions were being left behind. This is a rather small pr that corrects that.Notably,
bigIntToStringwas using_SIZES, which created a closure in every program. I did some additional optimizations while looking at the function._SIZESarray and closure dependency.getDigit, which removes a secondary closure and allows us to lazily initialize_DIGITSsaving some bytes.resultso we don't need to iterate over the result buffer again. (This also removed a helper function.The second change was much smaller; we were creating a function in pervasives called
setupExceptions. This was being done because previously the exception handling interacted with some unsafe code; however, now it's completely safe, so we can drop the function wrapper, which saves a few bytes.Just as a note from what I could tell in the binary, our smallest program is pretty well optimized, with most of the remaining code being related to the exception handling setup we do in pervasives. I don't really see much room left to optimize this away, however, beyond determining if exceptions can be thrown in the program and eliminating them at the compiler level.
This work is based on: #2378