Excellent benchmark!
> 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.
> ;-))
Assuming that 80% of templates will generate new classes instead of
mutating an existing class we can definitely make it faster by not
instantiating jjtree AST objects. The best solution would be a runtime
flag which determines whether jjtree is needed or not. I mean say
CompilationUnit() does the jjtree.openNodeScope/etc only if
XJavaDoc.isJJTreeNeeded==true. We can set this flag *per template*, so
if a template generates a new class then true, else false. I'm not sure
it's possible but it'd be cool. We just need to wrap those jjtree.blabla
calls in JavaParser with if(needed) statement. We won't need two
grammars and two set of parsers/etc in this case. Aslak, do you think
it's possible?
> 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.
Flyweight is the way to go. I implemented a simple form of it with the
XJavaDoc.getXClass method, so all parameters/return-types/classes are
lazy loaded and the XClass pointer is null until it's accessed actually.
But we can enhance it, and as you said before just store the qualified
name of a class instead of the XClass object and so on. I would love to
see a very low overhead XMethod object (or lazy loading it altogether!),
most of the methods are not accessed at all. And it's even more true for
parameters.
And remember the XJavaDoc.getXClass is way more significant than you
think. Our xjavadoc parser may be *slower in parsing a single class* but
because we don't load/parse all classes like doclet our approach should
be tens of times faster! Specially when you rerun xdoclet on an already
built output, and you only changed a single ejb after the previous
build. Only that single class and its superclasses are scanned.
> 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.
I think it's ok. doc() is unintuitive and I don't think it's a major
problem in our migration. It's used in getTagsByName/etc not scattered
in code deeply.
The Type class is also not present in our hierarchy but I also think
this one is a good refinement of the doclet api. Type is used for
primitive types (not everything is a class). The way Type is used in
Sun's doclet api is wrong imho. Keep it as is. There's no MemeberClass
either, and this one is also fine. The hierarchy we have currently is ok
imho.
> public interface XClass extends ClassDoc {
> XClass superclassx();
> }
No no! Why? Bad idea! If migration proves to me very hard we'll start
adopting these kinds of adapting/decorating strategies.
For the moment: concentrate on completing the feature set, concentrate
on laying the ground for a generic optimization system. If we're going
to store the full class name only and no XClass object till needed then
we should adopt this strategy from the beginning.
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
