[jdom-interest] About FastFactory

[Alex Rosen]

I'm not sure how much I trust OptimizeIt (etc) anymore now that HotSpot
has come along. It's great for finding possible problem areas but not
very good at giving accurate timings - i.e. I take its findings with a
large grain of salt. Doing further tests is the right way to go.

Also, if we increase the capacity, that might make parsing faster but
leave around more unused memory afterwards, right?

Alex

>>> <phil at triloggroup.com> 5/28/2003 9:12:29 AM >>>
I know that having unchecked methods may lead to malformed documents if
people do not use it carefully. That's the
reason why I think adding such methods directly to the objects is not a
good idea, as they are exposed as the other one.
I took Brad approach, and simply created an UnverifiedFactory class,
that just exposes some creation and list
manipulation methods, bypassing all the checks. This ensure that people
who use that class are aware of the danger, and
thus assume the risk.

That class is designed to be used in different contexts, and not only
for SaxBuilder.
I tried that with Dennis Sosnoski XMLS and reported a performance gain
around 15%, measured with OptimizeIt.
Intuitively, I think that a custom SaxBuilder will provide a gain with
the same order of magnitude.

Also, OptimizeIt emphasizes that ~14% of the time was spent in
ContentList.ensureCapacity() (when using the set of
documents tested by Dennis, like much_ado.xml, periodic.xml...). This
means that the initial capacity is under
sized for these cases, and should be increased. This also means that
the formula "(oldCapacity*3)/2+1" is not accurate
and should probably be changed to something like "oldCapacity *2+1", or
even bigger.
I'll do some tests and let you know.