velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: performance questions - faster Introspector
Date Mon, 10 Sep 2001 04:09:26 GMT
Attached is a little modification to Attila's great work on the
Introspector.

I just gave it a little twist by keeping everything keyed by Class
instead of by class name. To do it was necessary to add an extra
map, but this one only gets to be used when there is a new class or
when a Class Loader got dumped.

This should keep things FASTER, especially after the introspection
cache is filled.

I am attaching the whole file, but there are not that many changes
from Attila's version. Please make a diff to see them.


Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Sunday, September 09, 2001 8:21 PM
> To: velocity-dev@jakarta.apache.org
> Subject: Re: performance questions
>
>
> On 9/9/01 3:24 AM, "Attila Szegedi" <szegedia@freemail.hu> wrote:
>
> > (I've redirected this to velocity-dev, hope you don't mind)
> >
> > Here's my stab at having Introspector detect class reloads and
> discard no
> > longer relevant ClassMaps. Right now it might seem a bit compex, as it
> > discards ClassMaps at class loader granularity. However if it
> is not granted
> > the required "getClassLoader" RuntimePermission, then it falls back
> > gracefully and simply clears the whole cache when it detects
> what seems like
> > a class reload.
>
>
> This is great - this is the same strategy that I took (which was
> really what
> you described in the first place), but didn't separate by classloader.  I
> just dumped the entire pile when something changed.
>
> I made some small changes to introspector for the separate runtime that I
> will check in today, so I will dump my classloader-change changes
> and put in
> yours after that and provisionally checkin so people can see if it solves
> the problem (it should...)
>
> I am still wary about two things, the general performance and the
> complexity
> of dumping all in a classloader, as we are assuming a lot there.
> Of course,
> dumping all is pretty inefficient, so dumping by classloader is smarter.
> However... :)
>
> >
> > I'm including both the diffs and the complete modified files (as
> > Introspector underwent a major rewamp, I feel it's better comprehensible
> > from complete source than from the diff.)
> >
> > I've run it against the test suite and it fails on single test,
> but I assume
> > it has nothing to do with these changes:
> >
> >    [java] There was 1 failure:
> >    [java] 1)
> > EncodingTestCase(org.apache.velocity.test.EncodingTestCase)junit.
> > framework.AssertionFailedError: Output 2 incorrect.
> >    [java]     at
> > org.apache.velocity.test.EncodingTestCase.runTest(EncodingTes
> > tCase.java:170)
> >    [java]
> >    [java] FAILURES!!!
> >    [java] Tests run: 1,  Failures: 1,  Errors: 0
> >    [java]
>
> That's weird...  Did it work before the change?  I wonder if it's output
> line terminator related.  I will toss in a small fix to see if
> that changes
> it for you.
>
> > In meanwhile, I'm thinking of making a test case specifically for this
> > functionality.
>
> geir
>
> --
> Geir Magnusson Jr.     geirm@optonline.net
> System and Software Consulting
> Developing for the web?  See http://jakarta.apache.org/velocity/
> If you look up, there are no limits - Japanese Proverb
>

Mime
View raw message