You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
In this PR, reading of interfaces and generic type parameters (also necessary for reading interfaces) is optimized similarly to the above-mentioned #17364 PR.
To verify the optimizations, all readings except for the readings of interfaces and generic parameters have been removed from typeDefReader.
The same benchmark data from #17364 was taken, and the following benchmark was written:
[<Benchmark>]member_.ILReading()=for fileName in assemblies doletreader= OpenILModuleReader fileName readerOptions
letilModuleDef= reader.ILModuleDef
for ilTypeDef in ilModuleDef.TypeDefs.AsArray()do
ilTypeDef.Implements |> ignore
[<IterationCleanup(Target ="ILReading")>]member_.ILReadingSetup()=// With caching, performance increases an order of magnitude when re-reading an ILModuleReader.// Clear it for benchmarking.
ClearAllILModuleReaderCache()
As you can notice, the search phase for the interface range has become faster, as a smaller amount of data is being read. The full reading only occurs when converting the found rows:
Profile for the sequential analysis of all files in Giraffe - src/Giraffe
Plans
It is also planned to make the computation of type interfaces lazy in a separate PR, since it is independent optimization/API change.
@DedSec256 Thanks for improving this. Would you be able to fix the conflicts?. I think these performance improvements will make a difference in large projects that relies on interfaces and extension attributes.
@T-Gro, There are some additional changes here related to reducing the copying of anonymous structures (and tuples creating) in private functions. Can I ask you to take a look yet another time?
@DedSec256 before merging this - could you please update the benchmark numbers, just to make sure that they still hold after all this changed merged meanwhile?
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.
Continuation of #17364
As stated in #16168
In this PR, reading of interfaces and generic type parameters (also necessary for reading interfaces) is optimized similarly to the above-mentioned #17364 PR.
To verify the optimizations, all readings except for the readings of interfaces and generic parameters have been removed from
typeDefReader
.The same benchmark data from #17364 was taken, and the following benchmark was written:
As you can notice, the search phase for the interface range has become faster, as a smaller amount of data is being read. The full reading only occurs when converting the found rows:
Profile for the sequential analysis of all files in Giraffe - src/Giraffe
Plans
It is also planned to make the computation of type interfaces lazy in a separate PR, since it is independent optimization/API change.