Optimization work. - #163
Merged
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.
This PR addresses old annotations and settings to squeeze out performance, which are barely relevant today, and may indeed be obsolete:
-funbox-strict-fieldsis dropped per a conversation with Claude. Modern GHC has better heuristics than it used to, and this setting appears to make performance microscopically worse.INLINEs are dropped. Claude advised me to keep them, but I think that is out of bias towards the status quo ante, whereas I see unnecessary annotations as distracting clutter. Apparently they do nothing since inlining happens anyway since GHC knows they're small, and most are in-module so there's not even a need. I kept the one that is cross-module, though it is small enough to likely not need it.UNPACKs are dropped. Claude similarly advised me to keep them, but I see no benefit. TheMsgfields in question are immediately copied into aJustwhere they're boxed anyway. The style inSegmentis looked up in a map and so presumably is always boxed at that point (plus it's almost always pulled from a data structure where it's already boxed, so why flatten?). I only kept the Segment ByteString as unpacked since maybe in some cases there is no boxing.In general, for this app, these are imperceptible sub-microsecond differences, so my inclination is to not annotate, that is, not second-guess GHC's defaults with extra stuff when it doesn't matter anyway. But if it's "right" to do it, it still makes sense, and there is a case for leaving a couple undisturbed. Hence the above choices.
Unrelatedly, I tweaked a test from the last PR to spare an import, and trimmed a few comment lines.