Hi Daniel,
Some points you may want to consider:
1. Unlike java.lang.String, XMLString is read-write. That means, whenever
the content of an XMLString is changed, your string field needs to be
cleared. This happens quite often in Xerces, because XMLString objects are
reused a lot. So if we perform such clearing, I suspect that your change
would actually slow Xerces down. You don't clear the string field at all in
the code you submitted, which I think is not correct.
2. If you design your application carefully, you don't need to call
.toString on the same XMLString multiple times. You use XMLString when you
want a writable String; when you reach the point where you only need a
read-only version, you call .toString, and pass the result on.
3. If you noticed a place in Xerces where we call .toString on the same
XMLString multiple times (when the content of XMLString doesn't change),
let us know, and we'll be more than happy to look at it, and possibly fix
it.
4. It'd be much easier for other people to understand your patch if you had
made a diff against the current code: diff -uw
> Since this change went in, we have noticed a significant decrease in
memory consumtion due to String creation from this method.
Did you check your DOM tree to see whether it still contains the correct
textual content (for elements)?
Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
Daniel
Butterfield To:
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
<dbutterf@Insight cc:
.com> Subject: Store String references in
XMLString
10/31/2002 03:15
PM
Please respond to
xerces-j-dev
Hi all,
���� I'm currently working on a large project that uses the dom tree
heavily.� We noticed in our vm profiles that a large portion of our memory
consumtion was as a result of .toString() <<XMLString.java>> � As a result,
I've modified the XMLString class to store a reference to the string once
the toString() method is called on that object.� My question is, is this
the correct way to address the problem of excessive String being created
from this method, and do you see anything wrong with this approach?
(Attached is a copy of the code changes I made
���� Since this change went in, we have noticed a significant decrease in
memory consumtion due to String creation from this method.
Dan
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
#### XMLString.java has been removed from this note on October 31 2002 by
Sandy Gao
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
