-
-
Notifications
You must be signed in to change notification settings - Fork 111
perf: cache GetAttributeObjectInitializer
#4600
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
|
Realised that because the compilation is always the same in the benchmark, Still excellent, but I might make
|
4371870 to
86f3855
Compare
|
Sorry, rowing right now. I had a better idea to handle caching while respecting stateless generator runs. This shouldn't be merged |
86f3855 to
be424fa
Compare
|
Instead of having a I did this previously with Mapperly, where |
be424fa to
e1f48e3
Compare
|
Is modular pipelines failing on windows just a quirk? |
Use
ConditionalWeakTableto cacheGetAttributeObjectInitializer.ConditionalWeakTableusesObject.ReferenceEqualsfor equality and does not count as a reference to theAttributeData, therefore it won't keep the object or attached compilation alive after it becomes stale.On a related note, I'm pretty sure
InterfaceCacheshould be causing a memory leak by keeping most staleCompilationobjects alive. I have no idea why this hasn't become an issue.Note that the benchmarks aren't completely accurate for real world scenarios. While
GetAttributeObjectInitializeris slow, I suspect the main issue is each method inTUnit.TestProjecthas at least 8 identical licensing attributes, making this a slightly misleading benchmarkBefore
After
Attribute bloat