> I don't understand what you mean here but I suppose
it is not important?
It's kind of important. Basically, I learned
that if you run into a StackOverflowError when serializing something, it's
most likely due to recursion. To solve the problem, don't do
recursion.
Okay, this seems to be irrelevant, in the sense that they are talking
about the Serialization in RMI terms of a linked list, this here is neither
RMI nor, more importantly, a linked list.
They mention that this isn't really an implementation
problem, but a problem with the serialization protocol, since it is not known
what the data structure is before it is created.
That is the problem with XML serialization also, it is not a linked
list but a tree so it is harder to get the recursion
out.
In that case, would it be beneficial to consider an
additional implementation that is not recursive?
I am sure someone from the Xerces team will be here shortly to say
that they welcome patches......
Maybe, maybe not. Personally, I wouldn't create such a
document. But I'm creating it for testing purposes.
I see your point...and 10,000 is an extreme case.
However, this is a consequence of the testing I'm doing.
Yeah, I figured it would be a test-document. Maybe you should
try a document with 10.000 attributes next, see how that
performs....
So, in short, would it be wise to consider a
non-recursive pre-order traversal of a DOM tree? (I'm assuming not since
I'm probably the only one who has ever asked...)
I already looked at how serialization should be done without recursion
(as in our product, we use recursion for serialization also), I then concluded
that it was not easily changable into tail-recursion (first step to changing
it to an iteration) so "no way I was going to implement
that".
Kind
regards,
--Sander.
