I have just added some more benchmarking code. Just run the benchmark
target.
There are now 4 benchmarks within that target. They all scan the xdoclet
sources. (Results from my machine).
1) Runs classic javadoc (using a no-op doclet that only measures time and
prints it to stdout)
4016 ms
2) Runs xjavadoc
5448 ms
3) Runs a jjtree generated parser that doesn't instantiate any objects.
2634 ms
4) Runs a javacc generated parser that doesn't instantiate any objects.
1001 ms
The conclusion is that the main overhead in xjavadoc is object creation, not
parsing. JJTree nodes and XJavadoc object creation accounts for 5448 - 1001
= 4447 ms, or 80% of the time. We have to reduce this!
Here is the strategy:
We can generate two versions of the parser. One JJTree based, needed for doc
mutation (XDoclet GUI and Reverse XDoclet) and one JavaCC based used for
XDoclet. XDoclet doesn't need to mutate the docs. We can use the same
grammar, just decide whether we preprocess it with JJTree or not. We should
preprocess the grammar file itself, to make sure the generated parsers go
into different packages. We can use XDoclet's ReplaceCopy task for this.
;-))
But this only removes the overhead of Node creation. We also need to reduce
the creation of xjavadoc objects, and that's more tricky. I reread the
flyweight pattern from GoF's Design Patterns, and I think that's a good
pattern to use. It's about sharing objects. We can start by flyghweighting
the XParameter class. We can make ParameterImpl a singleton, and each
MethodImpl can contain a two dimensional int array representing pointer to a
huge StringBuffer (which is a member of ParameterImpl) to extract the type
and name members. This way we don't have to instantiate a lot of heavy
String objects, we just append to the StringBuffer as we parse, and maintain
these int arrays. I want to start with ParameterImpl, because this is the
class that will probably be instantiated the most.
I've also been thinking abot xdoclet's API. The main difference from javadoc
in the current API is that XProgramElement has-an XDoc, whereas
ProgramElementDoc is-a Doc. Containment versus inheritance. I did it that
way when I designed it because I thought it was better design. I still think
it is, but we might get some benefits from being compatible with javadoc.
The most signinificant one being the ability to use all the doclets out
there (including the standard HTML API doclet). An other benefit is that
XDoclet's migration from javadoc to xjavadoc will be a no-brainer.
There are different ways to be javadoc compatible. We need to support the
same interfaces. Here are the options as far I can see:
1)
All Xxxx interfaces extend the javadoc interfaces. We'll have to rename the
current methods because the return statements and method parameters don't
match javadoc's API. In the impl classes, we'll implement the javadoc
methods, and they will just call the xjavadoc methods. Like this:
public interface XClass extends ClassDoc {
XClass superclassx();
}
class AbstractClass implements XClass {
public XClass superclassx {
...
}
public ClassDoc superclass() {
return superclassx();
}
}
This will make the API a bit messy/redundant, but who cares?
2)
We make javadoc class adapters (as opposed to object adapters, see GoF) of
xjavadoc in a separate package, e.g. xjavadoc.javadoc:
class AbstractClassDoc extends AbstractClass implements ClassDoc {
public ClassDoc superclass() {
return superclassx();
}
}
The parser would have to istantiate xjavadoc.javadoc classes during
parse. -No, wait that won't work, because superclassx isn't a ClassDoc. We
can do it with object adapters instead, but that means additional object
creation.
Well, you get the picture. We can discuss how to do this. I'd love to have
comments on optimisations an this API thingy. I guess the API stuff is lower
priority than performance. I'm sure I'll get good comments ;-) I've said it
before. -What a cool gang to do OS software with!
Cheers,
Aslak
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
