Le lun. 4 janv. 2021 à 12:41, Mark Thomas <ma...@apache.org> a écrit :
> 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. > Well it also depends the classpath. I fully agree with a plain tomcat not customized you don't get much - just have a more consistent usage of resources but it is about being purist so not that interesting to me here. Now make your classpath bloated - yes some people do ;) but I guess having ~100jars is not that rare too these days - and this is really slower, in particular with a custom security manager getResource check even if it got optimized. Another interesting case is the tomee one or more exactly: the embedded one. Let's assume somebody uses tomcat embeded (not rare these days) and its dependency resolution comes with a servlet-api which is not tomcat one (not rare too), then it can miss the resources because it is a pure API or the project it comes from grab them from elsewhere. Why would he get warnings if he does not use the validation. So to summarize I see two benefits to update a bit the impl: 1. Makes it smoother for embedded case (where validation is rare) 2. Makes is a bit faster for highly customized standalone instances (enterprise prebundled server/layer) Indeed I don't expect - can be done technically but hope it is never true - both to be true at the same time :s. > > 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) > Not sure I got this, it is just about chaging the internals of the map so API does not break (like overriding get to be lazy but not changing the generics). > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
