-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Optimize retrieval of simple name from Assembly.FullName, fix up faulty methods #9739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
f4173b4
to
072404b
Compare
Fix merge conflicts after #9744 |
@h3xds1nz, this PR can be taken in after the conflict resolution. |
Also, would it be possible to add some tests for this change as well? |
072404b
to
cf71a1f
Compare
@himgoyalmicro Awesome, now just the other one and I can continue the journey <3 Merge conflicts should be solved in the last commit, was kind of few wrong auto-merges of usings. Regarding tests, yeah, I'll get a PR in somewhere this week. |
Sorry for being a bit late but wouldn't it be better to use the new AssemblyNameInfo instead ? It should be faster than the existing code using AssemblyName and it might be slower than the custom parser that you implemented but it would be better than using our own parser that might contain bugs and that the WPF team would need to maintain. |
@ThomasGoulet73 It uses the same parser impl basically except it doesn't throw because it has As I've mentioned, I wouldn't use custom impl if it wasn't already parsed by the runtime parser. It is not a science and it is well documented what you need to escape. Plus WPF was already doing custom slicing and it was doing it wrong. |
I mean I wouldn't call it a "science" but I wouldn't call it straightforward either. The thing is your implementation does not do exactly the same thing as GetName/AssemblyName. Assembly names can contain chars such as '\t', '\n', '\r' or '\\'. You can see in your own test that if you use It most probably never happen in practice but I just wanted to make it known that it wasn't a 1-to-1 replacement. Also FYI I wrote a quick fuzzer to test it out: Code
That's true. It's not much faster but it allocates 1 less instance (AssemblyName itself), can be used with span and won't instantiate a CultureInfo if Culture != neutral. |
I have indeed missed that part and I would probably find out during writing the extended tests but I'm happy you've pointed it out. I have updated the fallback mechanism to use |
@himgoyalmicro This is now ready, last commit addresses a great concern from Thomas I've indeed missed and didn't test for. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@himgoyalmicro That is so sweet, thank you! Yeah I was planning to rebase that one. Glad we're thinking the same haha |
Description
Optimizes retrieval of simple name from
Assembly.FullName
and removes all the weird ways used throughout to get it, this optimizes both startup and runtime performance.Baml2006Reader
andXamlSchemaContext
the original method did not properly parse assembly names with properly escaped commas, a weird edge-case but still a valid one. This was there due to CAS anyways.RuntimeAssembly
, usingassembly.GetName().Name
is always the slowest, followed bynew AssemblyName(assembly.FullName).Name
.SafeSecurityHelper
to its ownReflectionUtils
static class.FullName
is already afterAssemblyName
parser sanization, and withRuntimeAssembly
(even dynamic assemblies fromAssemblyBuilder
), we can just look for a separator, there should be no concerns with custom parsing.net472
fallbacks tonew AssemblyName(assembly.FullName).Name
.Benchmarks for RuntimeAssembly
Benchmark code
Benchmark code
Customer Impact
Improved startup/runtime performance, decreased allocations.
Regression
No.
Testing
Local build, sample app run, assert tests.
Risk
In my mind it is low, all places I've tested are passing
RuntimeAssembly
, so there should be no surprises.Microsoft Reviewers: Open in CodeFlow