velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <>
Subject Re: performance questions - faster Introspector
Date Mon, 10 Sep 2001 08:01:08 GMT
Attila Szegedi wrote:
> Hmm. So, if I'm right you'd be happier with per-classloader dumping of
> cache? (I have this already coded, but have phased it out in agreement with
> Geir in spirit of the KISS principle).
> Attila.

Honestly, I'm just a happy Velocity user. Even if I had to stop/start
Tomcat every week to prevent memory leaks it'd be fine by me. Well,
almost, anyway.

However, this is like with one of those Linux kernel locking issues - do
we make things more granular and more complex or less granular and less
complex (not that I'd be able to program any)? I guess it depends on
what you want to achieve - on a single CPU system the first approach is
an overkill, on a 64 CPU machine it's a necessity. You know, the Irix

To get back to Velocity, since non-singleton model was introduced, I
guess it makes sense to have Velocity jar in lib/apps. And on a big
server running a lot of Velocity apps, especially if some of them are
experimental (ie. you let people poke around, deploy their own
templates, beans etc.), dumping of the whole lot would hurt other apps
(potentially other customers). So, yes I'd be inclined to vote for
complexity here.

One other idea might be to not have static fields in the Introspector,
but rather make them regular private class fields and then keep the
logic simple since it would already be per classloader. But that would
probably increase the overall memory usage of the cache since there
could be duplicates of classes/methods in multiple instances of
Introspector cache. I'm not really sure what I'm talking about here but
what the heck...

Either way, I'm OK. Slightly more OK with a complex solution though (I
actually rather liked the Weak* thingies but someone pointed out the
performance penalty).


View raw message