So if it's that slow, what do you think about keeping a hashtable of found classes and packages in xjavadoc? Btw I'm sure it'll be faster than Class.forName in system classpath too.
Also another BIG improvement is adding a isBinary() method to XClass or even a (...,boolean accept_binary) to all methods which return an XClass such as superclass() or interfaces(). Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-user- > [EMAIL PROTECTED]] On Behalf Of Aslak Helles�y > Sent: Friday, June 21, 2002 12:32 AM > To: Rich Steele > Cc: Ara Abrahamian; Marcus Brito; Lista XDoclet-User > Subject: RE: RE: [Xdoclet-user] Very slow performance over network drive > > > > > -----Original Message----- > > From: Rich Steele [mailto:[EMAIL PROTECTED]] > > Sent: 20. juni 2002 21:20 > > To: [EMAIL PROTECTED] > > Cc: Ara Abrahamian; Marcus Brito; Lista XDoclet-User > > Subject: RE: RE: [Xdoclet-user] Very slow performance over network drive > > > > > > > > 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()). > > > > I was lying to you. I hadn't committed it. DOH! I just did. Maybe you can > benchmark again. Sorry that I made you think I had committed it. The > marginal improvement you saw must be something else. > > Aslak > > > 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 ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
