Why cache to XML if you're looking for super performance? Wouldn't
serialized objects be even quicker? I haven't a clue how xjavadoc works
internally, but my hunch is that it builds an object graph representing
classes/methods/fields and their @tag data.
Just an idea.... dunno if loading serialized objects is faster than SAX on
XML files and rebuilding the object graphi, but seems like it would be.
Erik
----- Original Message -----
From: "Aslak Helles�y" <[EMAIL PROTECTED]>
To: "Bart Guijt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 27, 2002 8:06 PM
Subject: RE: [Xdoclet-devel] [RT] Persisting parsed data?
> That's a very good idea! During development of xjavadoc we made some
> benchmarks that showed that parsing was 4-5 times faster than javadoc.
That
> turns out to be only partially true. xjavadoc is very fast as long as the
> class body isn't parsed (i.e. only class level tags and class info is
> requested). When any info in the class body is requested (such as methods,
> fields and constructors) the rest of the source file is parsed, and that's
> when things slow down. In short, the benchmarks were badly interpreted.
>
> In practice, all classes will always be parsed completely (happens if at
> least one xdoclet template does a forAllClasses/forAllMethods - nearly all
> templates do this). Result: xjavadoc is slower than javadoc. Since
xjavadoc
> is based on JavaCC, and already uses any imaginable optimisation technique
> allowed by JavaCC, we can't improve source parsing performance
considerably
> more than it already is.
>
> -And that's why your idea is fantastic. We can persist the class info in
an
> XML format and parse that instead using SAX. A lot faster! For the time
> being, there are tasks with higher priority, like fixing the numerous
issues
> registered in the SF bug/feature tracker. When we get back to acceptable
> functional performance, we should definitely get back to this persisting
> thing. It would make xjavadoc lightning fast!
>
> I know there are numerous strategies for representing java as XML out
there,
> but I think we should design our own proprietary format so we can tune
> performance to our needs. I don't think there is a lot to gain from
> following a "standard". We should of course study how this is done by
other
> products to get useful input.
>
> I'll be away on Easter holiday, so I won't be able to follow this
discussion
> in a few days, but I hope people will comment on this. We should also
> contact Joshua Bloch and discuss how this could fit in with JSR 175.
>
> Aslak
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bart Guijt
> Sent: 28. mars 2002 00:23
> To: [EMAIL PROTECTED]
> Subject: [Xdoclet-devel] [RT] Persisting parsed data?
>
>
> Hi,
>
> The parsing task of (x)javadoc takes a long time. It parses all files
passed
> in and then some subtasks (e.g. remoteInterface) decide to generate files
by
> comparing last modified dates.
> However, it seems that the parsing part takes the most time and I think it
> would be very worthwile to optimize the parsing part by loading already
> parsed data. xjavadoc simply reads all javadoc data, persists this and
> whenever a sourcefile is to be parsed again, xjavadoc checks the persisted
> data to decide whether to parse and so only parses changed sourcefiles. A
> little like JavaMake does, I guess.
>
> Are there any thoughts on this?
>
> Ciao,
>
> BG
>
>
> _______________________________________________
> Xdoclet-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
