[jdom-interest] Re: [jdom-announce] JDOM Beta10 released

Wed Feb 18 14:32:38 PST 2004

I would be very interested in this ability to control the initial size, I 
am working repeatedly with documents I know a lot about.

I have an en_en.xml which I know has about 4000 children, I also have a 
usd.xml which has about a 1000 and a config.xml which averages about 10 
and I have one which only has a few children but is very nested so I 
assume setting to 1 would be quite slow but very compact (but then this 
one is loading when the servlet starts so space is more important than 
time)

A setting to control these before I build a document would be welcome.

Any help of creating a faster, non validating parse would be helpful as 
the documents I am parsing in are the ones I created (persistence) so 
there is no point in validating them as JDOM created them.

/Phill
IS Dept, Software Engineer.
phill_perryman at mitel.com
http://www.mitel.com
Tel: +44 1291 436023

"Bradley S. Huffman" <hip at cs.okstate.edu>
Sent by: jdom-interest-admin at jdom.org
18/02/2004 17:08

        To:     phil at triloggroup.com
        cc:     jdom-interest at jdom.org
        Subject:        [jdom-interest] Re: [jdom-announce] JDOM Beta10 released

phil at triloggroup.com writes:

> I'm very pleased to see that JDOM is being officially released soon. Mo=
> reover, it features new capabilities like Content class that will make =
> our work easier!
>
> I still have just one concern with the API, that forces us to provide o=
> ur own build to customers. It's about optimization, when you want to co=
> nstruct a DOM without going through any validation stuff, because you p=
> erfectly know that your DOM is valid. Typically, we currently do this w=
> hen building an HTML tree programmatically (the build class is machine =
> generated from HTML source). 
> We already spoke about this earlier, and I want to reanimate the debate=
> because it may gain up to 20/25% execution speed. 
>
> You'll find a copy of the changes I made and now working with Beta 9 in=
>  production. To please Eliott and prevent people from doing something b=
> ad, all these &quot;unverified&quot; methods must be called as static m=
> ethods from UnverifiedFactory class. I joined to the mail the pieces of=
>  code that does the trick.  Nothing changed in the API, it is just an a=
> dd-on.. Because of class scopes, there is now way to make it running wi=
> thout providing a custom build. 

Jason just moved JDOMFactory out of package org.jdom.input and into
org.jdom so users can have a custom factory to skip verification from
trusted sources, so that pretty much eliminates the need for the extra
createElement, etc. methods.  And since it has moved, putting a "fast"
version of JDOMFactory in contrib would probably be a good idea at this
point.

But I don't see how the static addContent methods help.  Elements can have
anything as children except a DocType so all your skipping is one 
instanceof
test and a check for a null parent.  But the potentially biggest time 
waster,
reallocation of the content array, remains intact. But that assumes the
number of children in most of a document's elements greatly exceeds the
INITIAL_ARRAY_SIZE and causes excessive array reallocation. Something only
profiling can support or disprove, and then only on a case by case bases.

One problem I do see, which falls under the TODO item "ensure JDOM is
appropriately tweaked for subclassing", is if your problem would benefit
from a larger INITIAL_ARRAY_SIZE, I don't see a easy to do it currently.

Brad
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://jdom.org/pipermail/jdom-interest/attachments/20040218/e8f0b693/attachment.htm