SpringConfigurationPropertySource.DelegatingPropertyMapper.callMappers() is showing up in Flight Recorder as a source of GC pressure (the main source when only executing LoggingApplicationListener in a tight loop). It gets called a lot, and creates a lot of temporary arrays.
SpringIterableConfigurationPropertySource.getPropertyMappings() was a close second on the GC pressure hot list.
Kind of a special case of #13565.
Comment From: dsyer
There's a lot of caching going on as well in SpringIterableConfigurationPropertySource and on balance I think that might save us from actually experiencing the GC pressure that the tight loop showed up above. One change that might be worth making would be to try and ensure that this cache gets re-used - e.g. by making sure that only one Binder is created per SpringApplication or per Environment. If I do that in the tight loop test above (i.e. re-use the same Binder) the GC pressure from PropertyMapping and ConfigurationPropertyName disappears and the overall performance improves by a factor of about 2.
Comment From: wilkinsona
The tight loop is a bit of a micro-benchmark. Can you quantify the contribution to GC pressure in a more real-world scenario please?
SpringConfigurationPropertySource.DelegatingPropertyMapper.callMappers() is showing up in Flight Recorder as a source of GC pressure
Is this from the tight loop or from a "proper" app? I'm asking so that we can prioritise this accordingly.
Comment From: dsyer
It's real, and the microbenchmark is really just to show how bad it is if you zoom in on it. So the answer to your specific question is that it's only visible as GC pressure in the microbenchmark, but you can see the processing time spent in Binder clearly in a "proper app". We spend a lot of time, relative to the benefit (IMO) doing metadata construction in Binder during startup. I don't have an accurate figure, and it's hard to measure (hence the microbenchmark), but it's probably as much as 10%.
However, if we are talking about priorities, I would say that it is better to see this as part of #13565. The comments above indicated as much. It wouldn't be so bad to do this work once (even if some of it is unnecessary), as long as it could be re-used. I think it is mostly to do with creating the canonical form of all System property and OS environment variable key names. The key names are mostly immutable, and even if the user is setting System properties at runtime, we could still cache more to reuse this metadata.
Comment From: SeifMostafa
Hello, Any help?
Comment From: philwebb
@SeifMostafa Please stop asking the same question on multiple issues.