Optimization: Cache GetTypeByMetadataName in AttributeDataAccessor

[TimothyMakkison]

Profiling/benchmarking shows that GetTypeByMetadataName is slow and memory expensive.

Mapperly should probably use a Dictionary<Type, INamedTypeSymbol?> cache in MappingBuilderContext or WellKnownTypes. This could be considered for #390 and verified with the benchmarks. Iirc it sped up the generation time for the integration tests by 20%.

[latonz]

Thank you for profiling 😊
That is exactly why WellKnownTypes was introduced in the first place. WellKnownTypes lazily loads the types and stores them in fields. As there are lots of fields it could be refactored to remove the countless fields and add a dictionary as cache. I could only find two other GetTypeByMetadataName invocations, one in the MapperGenerator to resolve the MapperAttribute and one in the AttributeDataAccessor. These could also be moved to the WellKnownTypes. Especially the one from the AttributeDataAccessor as it is called several times for the same attribute.

I'm not sure about the approach of #390, that's why I paused working on it. The idea was to read all configurations ahead of time instead of the current on demand approach. WDYT about it?

[TimothyMakkison]

I could only find two other GetTypeByMetadataName invocations, one in the MapperGenerator to resolve the MapperAttribute and one in the AttributeDataAccessor. These could also be moved to the WellKnownTypes.

I don't think it's worth moving GetTypeByMetadataName from MapperGenerator into WellKnownTypes, aside from in MapperGenerator Mapperly never gets the MapperAttribute type. AttributeDataAccessor should definetely use WellKnowTypes

I'm not sure about the approach of #390, that's why I paused working on it. The idea was to read all configurations ahead of time instead of the current on demand approach. WDYT about it?

I liked record MappingConfiguration I think it makes sense to have all the configurations in one accessible area. I forked the changes to play around with nested ignores, having configuration in one place was handy to check if a mapper could be reused with the same types. I'm not sure if there is a major drawback to eagerly reading the configurations. I'd have to think about it more.

[TimothyMakkison]

Made a branch with the changes. I'll make a pull request when the benchmarks are added.

Looks like it benefits mappers with many mapping methods, saves 8ms for LargeCompile and saved 300 KB of memory. Doesn't look like Compile is effected.

Benchmarks taken from #419

Old:

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
Compile	1.563 ms	0.0261 ms	0.0244 ms	82.0313	19.5313	169.32 KB
LargeCompile	59.450 ms	1.1351 ms	1.1148 ms	1428.5714	285.7143	9280.05 KB

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
Compile	1.536 ms	0.0238 ms	0.0211 ms	82.0313	19.5313	170.23 KB
LargeCompile	57.525 ms	0.5249 ms	0.5155 ms	1428.5714	285.7143	9276.68 KB

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
Compile	1.571 ms	0.0240 ms	0.0225 ms	78.1250	15.6250	169.85 KB
LargeCompile	58.310 ms	0.9858 ms	1.2819 ms	1428.5714	285.7143	9272.75 KB

New:

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
Compile	1.594 ms	0.0303 ms	0.0384 ms	78.1250	15.6250	168.44 KB
LargeCompile	51.705 ms	0.8099 ms	1.1616 ms	1375.0000	375.0000	8934.55 KB

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
Compile	1.575 ms	0.0284 ms	0.0304 ms	89.8438	23.4375	168.49 KB
LargeCompile	51.513 ms	0.7022 ms	1.1924 ms	1333.3333	333.3333	8965.35 KB

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
Compile	1.559 ms	0.0296 ms	0.0277 ms	78.1250	19.5313	169.52 KB
LargeCompile	51.809 ms	0.9939 ms	1.0207 ms	1375.0000	375.0000	8925.2 KB

[latonz]

This got implemented in #478