RAR performance improvements on Core#2192
Merged
rainersigwald merged 5 commits intodotnet:vs15.3from Jun 9, 2017
Merged
Conversation
* Use null propagation to reduce nesting * Avoid a redundant comparison in an or clause * Ensure that the produced dependencies list is big enough to hold the input dependentAssemblies without reallocating.
Avoid creating and disposing a FileStream in both FrameworkName and Dependencies (usually called together) by populating both fields when either is requested and no-oping the second read. I tested doing this in both orders and this seemed to be consistently faster.
80dcbc4 to
c9a846f
Compare
cdmihai
reviewed
Jun 9, 2017
Contributor
There was a problem hiding this comment.
I'd put RAR in the names of the escape hatches.
c9a846f to
fe24685
Compare
cdmihai
reviewed
Jun 9, 2017
Contributor
There was a problem hiding this comment.
Shouldn't this be different instead of equals? Cache when ("Do not cache" is not 1)
fe24685 to
c713f47
Compare
RAR read assembly metadata twice for each resolved assembly, because referenceTable.ComputeClosure is called twice from RAR. Instead of doing I/O both times, cache the AssemblyInformation objects for each path for the duration of the RAR task, ensuring that each assembly is read only once. This allows configuration through the environment in two ways: .NET Core defaults to the new once-per-RAR-task reading, but can go back to the twice-per approach when MSBUILDDONOTCACHEASSEMBLYINFORMATION=1, and full framework continues to use the old approach but allows opting in to caching by setting MSBUILDCACHEASSEMBLYINFORMATION=1.
c713f47 to
55f846e
Compare
This is a performance win even on Full Framework, so enable it everywhere (with an escape hatch).
AndyGerlicher
approved these changes
Jun 9, 2017
cdmihai
reviewed
Jun 9, 2017
cdmihai
reviewed
Jun 9, 2017
Contributor
There was a problem hiding this comment.
I sure wouldn't want to construct a new ReferenceTable :)
Member
Author
There was a problem hiding this comment.
If you hadn't been out yesterday afternoon I was going to send you that set of parameters and have you guess what the heck it was for :)
Contributor
There was a problem hiding this comment.
Factory method for a new Big Bang.
cdmihai
approved these changes
Jun 9, 2017
This was referenced Jun 13, 2017
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.
I recommend going through this commit-by-commit; a couple of commits are straightforward refactors that look complicated in the final diff.
There are two improvements here:
AssemblyInformationextraction, read a file only once, populatingDependenciesandFrameworkNamewith a singleFileStreamAssemblyInformationfrom a given path exactly once (instead of twice).This chips away at #2015.