On 3/8/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > I believe I did some tests at that time and didn't seem so bad. > > It's not like it's going to read the strings/files on each request - > > it's loading them > > once, and will stay in memory for all the 'hot' jsps. The difference > > between a > > static final String access and a loaded String is not that big, and > > for GC - it'll > > get to the old generation quite soon. > > > > Do you have any test - or technical reason - why it would be 'really bad' ? > > I'm very interested - it's allways good to learn new things about GC... > > In any case - my thinking at that time was that this should be the > > default mode for 3.3 if it matures. Not sure what was the exact > > benchmark I used - but I was quite obsessed with performance. > > I believe serving multiple uncached small files as part of a single > request will have bad performance. If using properties files, pre > request parsing will be involved, which seems costly. I don't see how to > avoid this issue.
Why would anyone serve 'uncached small files' or parse properties on each request ??? Well, maybe that was the (incomplete) implementation long ago - and I agree, it would be really bad for performance. The static file can be loaded in init(), in a cache ( LRU or more complex, or just a weak reference ) - if the jsp is not used for a long time and the strings get GC, it'll have a small hit on the next usage - similar with the initial load. And it might have a small impact because of the cache and the weak reference versus final Strings. But I think it may compensate in other area - the memory is a very unpredictable thing, I've seen many cases where reducing the pressure and having more free space is faster than keeping everything in memory when the load is high ( because hight load usually means a small portion of the code is hit hard, and makes use of the extra memory, etc ) Anyway - there is no point trying to predict how performance will be affected, if there is a patch it's easy to check. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
