This seems marginally better.  The number of calls in
XJavaDocTask.execute() to AntClassLoader().loadClass(String, boolean)
has been reduced from 1100 to 773.  There is a similar reduction in the
number of calls to AntClassLoader.findClass(String) and
AntClassLoader.findClassInComponents(String).  However,
findClassInComponents() is still calling getResourceStream() over 20,000
times.  (The time here is evenly split between File.exists() and
File.isDirectory()).

However, the task still takes about the same amount of time as
before--over 10 minutes.  And remember, this is running the task against
*local* Java source files.

Thanks for all your help!

Rich

-----Original Message-----
From:   [EMAIL PROTECTED]
Sent:   Thu 6/20/2002 10:36 AM
To:     Rich Steele
Cc:     Ara Abrahamian; Marcus Brito; Lista XDoclet-User
Subject:        Re: RE: [Xdoclet-user] Very slow performance over
network drive

Hi!

----- Original Message -----
From: "Rich Steele" <[EMAIL PROTECTED]>
Date: Thursday, June 20, 2002 4:01 pm
Subject: RE: [Xdoclet-user] Very slow performance over network drive

> 
> I enabled logging for xdoclet.taghandlers.MergeTagHandler, but I don't
> see anything from the MergeTagHandler in the log file.
> 
> I ran my Ant build in JProbe with a network installation of 
> XDoclet and
> a local ("snapshot") view of my source files.  Not completely done yet
> (I want to do the same thing but with a locally installed 
> XDoclet), but
> I get some interesting stuff:
> 
> o Of the cumulative time spent in the XJavadoc.execute() method, 
> 65% of
> the cumulative time is spent making over 1100 calls to
> AntClassLoader.loadClass(String, boolean).
> 

When xjavadoc parses a source class, it tries to discover the full 
class hierarchy, and that involves loading all classes and interfaces 
it extends.

xjavadoc will first try to find the source for a class, but if the 
source isn't available, it will try to load the compiled class.

After a class is loaded, it will use introspection to figure out all 
classes that are referred to by the class' methods and constructors, 
and this explodes into loading of a *lot* of classes.

I realised yesterday that this is (probably) completely useless, as we 
only care about fields/methods/constructors for source classes, and 
nnot for compiled classes. -We also care about the class hierarchy.

Therefore I changed the code so that methods and constructors of 
compiled classes are never looked at. The net result is that 
(dramatically) fewer classes are loaded, and this should improve 
performance quite a bit. I haven't benchmarked this though, but maybe 
you can?

I committed the changed code yesterday night, so if you CVS update 
xjavadoc, you should have something *much* faster (I hope).

Cheers,
Aslak

> o Almost 97% of the time spent in AntClassLoader.loadClass(String,
> boolean) is in AntClassLoader.findClass(String).
> 
> o Over 99% of the time in AntClassLoader.loadClass(String, 
> boolean) is
> spent 
> in AntClassLoader.findClassInComponents(String).
> 
> o AntClassLoader.findClassInComponents(String) spends 98% of its time
> making almost 30000 calls to
> AntClassLoader.getResourceStream(File,String).
> 
> I could go on if you want.  This probably is all irrelevant until 
> I can
> do another test with a locally installed XDoclet...
> 
> Rich
> 
> 
> -----Original Message-----
> From:        Ara Abrahamian
> Sent:        Wed 6/19/2002 3:41 PM
> To:        Rich Steele; 'Marcus Brito'; 'Lista XDoclet-User'
> Cc:        
> Subject:        RE: [Xdoclet-user] Very slow performance over network
> drive
> 
> This may have something to do with lots of merge file checks. Try
> enabling logging for xdoclet.taghandlers.MergeTagHandler and see 
> what'sgoing on there.
> 
> Ara.
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:xdoclet-
> user-
> > [EMAIL PROTECTED]] On Behalf Of Rich Steele
> > Sent: Wednesday, June 19, 2002 7:27 PM
> > To: Marcus Brito; Lista XDoclet-User
> > Subject: RE: [Xdoclet-user] Very slow performance over network drive
> > 
> > 
> > Yes dynamic views are slower; everyone expects that.  However, 
> if I
> > change my configuration to use a locally-installed XDoclet running
> > against the Java source in the dynamic view, the task finishes in
> about
> > 3 to 5 minutes (as opposed to the 30+ if XDoclet runs over the
> network).
> > 
> > If I run a network-installed XDoclet against local Java source 
> files,> it's still very slow. This makes me believe the problem 
> isn't because
> > the Java source files are fetched across a network connection;
> instead,
> > something funny is happening when XDoclet is loaded over the 
> network.> 
> > Rich
> > 
> > 
> > -----Original Message-----
> > From:        Marcus Brito
> > Sent:        Wed 6/19/2002 10:05 AM
> > To:        Lista XDoclet-User
> > Cc:
> > Subject:        Re: [Xdoclet-user] Very slow performance over 
> network> drive
> > 
> > 
> > 
> > 
> >
> -------------------------------------------------------------------
> -----
> --
> > --
> >                    Bringing you mounds of caffeinated joy
> >                    >>>     http://thinkgeek.com/sf    <<<
> > 
> > _______________________________________________
> > Xdoclet-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/xdoclet-user
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
>                   Bringing you mounds of caffeinated joy
>                   >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
> 






-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Reply via email to