Conversation
This does two things primarily: 1. Replace the jflex Reader-based lexer with a hand-written one (comes from TR with some changes -- very nice they have the exact same tri-license as us for that lexer!). 2. Remove making multiple smaller fragments for the result value with a single one which is passed around and written to directly. The main exception to this is padding where we cannot write since we don't know how long the value is relative to the padding width. I have not benchmarked this at the smallest level of just calling strftime directly (which is something I plan on doing soon). I did take a bench mark of calling through Logger. This works thus far improves that benchmark between 2.2 (default params) and 2.8 times (-Xcompile.invokedynamic).
For 9.3 less objects the better. Once we get a proper callsite cache we will reverse this and make a richer parse which creates more objects for faster strftime execution.
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.
TL;DR strftime is faster. For the format string used in logger it is 3.3x faster.
The general strategy for these changes was to eliminate object creation. The first round was just removing small bytelists in exchange for writing to the eventual result bytelist (only stymied by padded results where the value's length is unknown). The second was just reducing anything which was making an object per call.
Once we get a proper callsite cache the lexer/parser part of this can make more objects and pre-calculate things like what
padding it used etc. This in turn can lead to more custom evaluators which can lead to less code and less objects. That hoever is destined for 9.4+.
Here are results: