Changes to speed up Configuration #509
Conversation
| .Where(x => IsMappingOf<IMappingProvider>(x) || | ||
| IsMappingOf<IIndeterminateSubclassMappingProvider>(x) || | ||
| IsMappingOf<IExternalComponentMappingProvider>(x) || | ||
| IsMappingOf<IFilterDefinition>(x)) | ||
| .Each(Add); | ||
| .AsParallel().AsOrdered().Select(t => t.InstantiateUsingParameterlessConstructor()).ToList()) |
There was a problem hiding this comment.
This could be a possible breaking change for applications needing to spare as much as possible the threads count they are using. Of course normally configuration happens at startup, at a time where sparing threads usually matters less. But that may not be always the case.
So, I think we need a way to choose not to use any parallelism for building the mappings. And enabling parallel build should rather be opt-in, to avoid being a possible breaking change needing a code or config change to be reverted for existing applications.
…configuration will default to 1
|
Pushed up a change so number of threads can be set when configure is called. I did not mean to click the merge button and am sorry if that causes any issues. Hopefully nothing happened because I do not have write access but very sorry if it did cause any work. Thanks |
Improve mappedmembers efficiency
Create a suite of {I,}HbmConverter* classes and interfaces structured as a
parallel hierarchy to the {I,}XmlWriter* classes and interfaces in order to
support direct-to-HBM configuration conversion.
* Modify the base conversion interfaces to require fluent types to implement IMapping * Use a more intuitive type abbreviation for fluent types
(cherry picked from commit 4243130)
Note that this commit covers both IComponentMapping→* and ReferenceComponentMapping→* converters.
Hbm direct conversion
Cache typestrings to avoid significant duplication
Our object model has way too many model classes which I recognize is a problem but would like for it to start up as fast as possible. Here are three small changes that speed up our configuration a lot.
First is putting creation of MappingXmlFile into a parallel stream for my computer and our large object model. This reduced start up by about 7 seconds (this change also has the benefit on my computer of making the time to run all of the Fluent Tests from 17 seconds to 10 seconds).
The second change is putting the creation of the mapping classes into a parallel stream for my computer and our large object model. This reduced start up by about 10 seconds.
The third change is to extract property.Name into a var so it does not have to be executed every time inside of the Any loop. This reduced our startup by about 8 seconds.
Please let me know if you have any questions or would like more information. Thanks