Probably a good idea, but I hope we won't start implementing IDEA's local vcs cache or something like that!! Let's forget it for as long as possible. It's always frustrating to deal with stale/corrupted caches, when someone overwrites something or reverts back to an older version or ....
Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-devel- > [EMAIL PROTECTED]] On Behalf Of Aslak Helles�y > Sent: Thursday, March 28, 2002 5:36 AM > To: Bart Guijt; [EMAIL PROTECTED] > 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 _________________________________________________________ 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
