perf: cache GetAttributeObjectInitializer#4600
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