[jdom-interest] AttributeList performance

[Martin Schulz]

we have been running into a performance problem caused by the O(N) 
performance characteristic
of the JDOM AttributeList in the indexOf method.  This affects both 
insertions and lookup of Attributes.

Our application uses hundreds of Elements, each of which may have 20-40 
attributes.
In essence, the application (ab)uses the Element attributes as properties.

The visible effect for us is a noticable slowdown, e.g. a by a second or so.

We now face the choice to
a) speed up JDOM internally
b) subclass AttributeList and implement it more efficiently
c) build a HashMap from the AttributeList externally
d) not use Element attributes for this purpose

Being naive about XML, my first question is whether the order of
attributes is either significant or within JDOM guaranteed to be stable
as part of any API contract, or is it considered a 'nice-to-have'?

My other question to the list is whether this is something
worth fixing in general.  My use case may sound absurd and exotic,
but with the widespread use of JDOM I wouldn't be surprised if this
were a lingering problem for others.

A quick search of the mailing list doesn't indicate that the internal 
datastructures have
been publicly scrutinized for performance; on the other hand, everything 
appears
just to work well enough.

There might well be an implementation trade-off where the current 
default (array of 5 Attributes)
is the better choice compared to adding a datastructure with a bigger 
footprint, so I'd
be curious about what others might deem appropriate in this situation.

Thanks for your advice.

   Martin