Hi! Here is a short list of what I can think of now. Deferring class parsing is a good idea. it should boost the speed.
The bugs that I know of are: 1) package visibility classes/methods' javadoc is not properly read. I'll fix. 2) if a class implements an interface only available as binary, it seems it's not discovered. see xdocletgui. nothing shows up under tag libraries. Enhancements that can be done. 1) simplify the java grammar. it's useless/time consuming to parse the method bodies. 2) general javacc optimisations, like making parser static etc. structural enhancements/refactorings 1) expose less of the api. make more classes/methods package private. 2) remove the classicwrapper/xml packages. they were for testing at an early stage, but the junit stuff is sufficient now. _____________Original message ____________ Subject: RE: [Xdoclet-devel] Surprise! Sender: "Ara Abrahamian" <[EMAIL PROTECTED]> Date: Sun, 27 Jan 2002 09:00:02 +0100 OK, AFAICS it seems it's actually easier to optimize xjavadoc stuff :-) I'll concentrate on it. What's left undone in xjavadoc? Should I only concentrate on performance? Cheers, Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-devel- > [EMAIL PROTECTED]] On Behalf Of Ara Abrahamian > Sent: Saturday, January 26, 2002 11:25 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Xdoclet-devel] Surprise! > > > > Anyway, I received a request to make xdoclet faster. I'm going to > spend > > > some time on it. More specifically I'll try to do some magic > sourcefiles > > > reduction so that javadoc doesn't load all classes by default but > > > exactly those which at least one subtask needs to operate on. Any > ideas? > > > Tricks? Suggestions? Is anyone interested in doing a profiling? I'm > > > trying to prepare it for a 1.1.2 release. > > > > > > > Wouldn't it be better to put in the effort of making xjavadoc faster > > instead? -Or would that be in addition? There is a lot of > optimisations > > that > > can be done on xjavadoc. -And I presume the goal is still to ditch > javadoc > > in favour of xjavadoc. > > It's in addition to xjavadoc and in fact it'll be beneficial to xjavadoc > too. I'm trying to find a way to exclude javadoc/xjavadoc > loading/parsing of a class if it's not needed to be parsed. Because the > loading/parsing part is the performance bottleneck it'll indeed result > in a very huge performance improvement. Of course xjavadoc will even > give us much more control, so for example even if a class is included in > sourcefiles list, we can postpone loading/parsing it to a later time > when it's actually accessed. I'll try and if it's harder than I think > I'll simply give up and put %100 time n xjavadoc and the lazy loading > scheme I talked about above. > > I already started working on xjavadoc, stay tuned for my comments/codes > ;-) > > Cheers, > Ara. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
