On 04/01/2021 08:59, Romain Manni-Bucau wrote: > Hi Mark, > > The proposal is to move the locationFor to a Supplier<String> instead of > eagerly loading the URL (means the maps passed to the resolver override the > read part to handle it) - or a fully lazy map impl works too. > Idea is to avoid to be able to hit locationFor() until it is used for the > related xsd.
OK. Now I think I understand the proposal. > Prefetching = preresolution if you prefer. Overall the goal is to resolve > only when used. Most of the xsd are always useless so no real reason to > have them ready and consume time and memory for nothing + log warning if > irrelevant for the app (some filter out the xsd from jars cause it saves > ~1M and does not change at all the runtime for them). You are looking at the uncompressed size of the schemas (currently 1.3M with Tomcat 10). The compressed size is ~230k. How important is it to save that 230k of storage? As much as I'd like it to be the case that every system strives for efficient use of all resources my experience is that, for storage at least, that sort of storage saving is viewed as insignificant even at the uncompressed size. A quick test suggests that the static initializer in DigesterFactory takes about 4.5ms to complete. A profiler indicates that the memory footprint of those two maps are 10.6k and 1.3k respectively. How much time and memory would typically be saved by this proposal? Like any proposed performance improvement, this is going to come done to comparing the increase in complexity with the expected performance benefits. The Maps are public but they aren't part of what we consider to be Tomcat's public API so while this would technically be an API change, I don't think that is a reason not to do this (or limit it to 10.1.x) Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
