[jdom-interest] Re: [jdom-announce] JDOM Beta10 released
Phill_Perryman at Mitel.COM
Phill_Perryman at Mitel.COM
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
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.
IS Dept, Software Engineer.
phill_perryman at mitel.com
Tel: +44 1291 436023
"Bradley S. Huffman" <hip at cs.okstate.edu>
Sent by: jdom-interest-admin at jdom.org
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 "unverified" 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
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
test and a check for a null parent. But the potentially biggest time
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.
To control your jdom-interest membership:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jdom-interest