[jdom-interest] About FastFactory

Dennis Sosnoski dms at sosnoski.com
Wed May 28 09:32:07 PDT 2003


Anything with the list sizes is going to be heavily dependent on the 
structure of the data. The much_ado.xml that you mention, Phil, is the 
marked-up text of the play. periodic.xml is from Elliotte, and has a lot 
of children of the root (for individual elements) with each child also 
having many children (characteristics of the element). Both are shallow 
but wide, so they may be atypical.

Is JDOM handling the list growth directly? If so, I think starting with 
something like 4 or 5 and doubling each time you run out of room is 
likely to give reasonable results.

  - Dennis

Alex Rosen wrote:

>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.
>




More information about the jdom-interest mailing list