perf: drop unneeded inline from TupleOps / containsOnly - #55
Merged
Conversation
|
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
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.
Summary
None of
foreach,indices,mapAs,toArrayOf,toorrealConsneed to beinlinefor their own logic — they were onlyinlinebecause they take aninlinecontainsOnlyevidence parameter, and Scala requires the enclosing def to be inline to accept an inline parameter. That evidence is a compile-time-only proof with zero runtime component, but forcing the whole method inline duplicates its entire body into every call site's bytecode. FortoArrayOfthat's an array-building loop, copied once per derivation call site in downstreaminline-heavy macro consumers — discovered via mcodec, where it inflated compile-sweep bytecode by 27% (4,986 KB → 6,330 KB at N=100 derived codecs) for a 1.5% compile-time win.Fix: drop
inlinefrom all of these — thecontainsOnlyevidence still gets discharged as a normal (non-inline)usingparameter at each call site, and the method bodies become ordinary shared code instead of per-call-site copies.Same treatment in
containsOnly.scala: the derivedgivens (Tuple.Tail,Tuple.Reverse,Tuple.Concat,Tuple.Zip, theTuple.Map-constant-map ones, the low-priority fallback) don't need to beinline giveneither —reflis a plain shared value, not something that needs re-derivation per call site. They're rewritten using theOf[T]context-bound shorthand for readability. TheTuple.Head/Tuple.LastConversiongivens became<:<givens instead — same identity-cast trick, but expressed as evidence discharged at the use site rather than an implicit conversion function that has to exist as a value.Verified downstream
commonstest suite: all green (includingToArrayOfTest,ToTest,ContainsOnlyTest,MapAsTest)made(macro library built oncommons): compiles and tests clean against this branchmcodec(macro-heavy derivation library, the actual bytecode regression site): 186/186 tests green; compile-sweep bytecode at N=100 derived codecs dropped 9,105 KB → 2,900 KB end to end (most of that frommade0.6.0's own unrelated rework, but this fix alone recovered a 6,330 KB regression down to below the pre-regression baseline)Test plan
scala-cli test .— all greenmade,mcodec) verified against a local publish of this branch🤖 Generated with Claude Code