Fix performance issue with CaseSensitivity enabled #76
Conversation
This file contains 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
When CaseSensitive is set to true from JaceOptions, performance should be significantly better than without case sensitivity. Case sensitivity setting was not passed to `FunctionRegistry` and `ConstantRegistry` constructors, which caused them to do extra lower case conversions in case variable dictionary was passed to the formula. Fixes [issue pieterderycke#75][1]. New benchmark was created to verify the fix. Benchmark needs to have variables which are provided to `CalculationEngine.Calculate()`, so VerifyVariableNames() gets called, which causes the extra calls to `ToLowerFast()`. Below results show ~200 ms improvement when Case Sensitive is true. Results table was created by running benchmark separately with and without fix and copying results to one table. | Engine | Case Sensitive | Formula | Total Iteration | Total Duration (fix) | Total Duration (no fix) | |------------|----------------|---------|-----------------|------------------------|-------------------------| | Interpreted |False |something2 - (var1 + var2 * 3)/(2+3) |1000000|00:00:01.6005267|00:00:01.5919016 | | Interpreted |True |something2 - (var1 + var2 * 3)/(2+3) |1000000|00:00:00.6069845|00:00:00.8390435 | | Compiled |False |something2 - (var1 + var2 * 3)/(2+3) |1000000|00:00:01.5865326|00:00:01.5770084 | | Compiled |True |something2 - (var1 + var2 * 3)/(2+3) |1000000|00:00:00.5930012|00:00:00.8189981 | Additionally: - Unit test which tests case sensitivity enabled throws when variable case does not match - Benchmark uses dictionary copy constructor to avoid throwing due to dictionary being modified with constants and then failing on `VerifyVariableNames()`. [1]: pieterderycke#75
|
@pieterderycke Any chance of getting this merged? |
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.
When CaseSensitive is set to true from JaceOptions, performance should
be significantly better than without case sensitivity. Case sensitivity
setting was not passed to
FunctionRegistryandConstantRegistryconstructors, which caused them to do extra lower case conversions in
case variable dictionary was passed to the formula. Fixes issue #75.
New benchmark was created to verify the fix. Benchmark needs to have
variables which are provided to
CalculationEngine.Calculate(), soVerifyVariableNames() gets called, which causes the extra calls to
ToLowerFast().Below results show ~200 ms improvement when Case Sensitive is true.
Results table was created by running benchmark separately with
and without fix and copying results to one table.
Additionally:
case does not match
dictionary being modified with constants and then failing on
VerifyVariableNames().