First of all, java.lang.StringBuffer doesn't seem to have a local reference
to the corresponding String, then why should XMLString have it? :-)
Back to our discussion:
I missed that you do clear the string field when setValues is called. But
as you can see, all fields (ch, offset, length) are public, so the content
of XMLString can be updated without calling setValues. The string field
won't be cleared in those cases, so .toString might return incorrect
results. We could make all these fields private, then introduce methods to
update them, and clear string field when those methods are called. But
there is obvious performance hit here. And I still believe we don't need to
call .toString on XMLString more than once.
> XMLString .toString() is being called as a result of
Element.getFirstChild().getNodeValue(); (Node.getNodeValue());
That is interesting. The Xerces DOM implementation doesn't refer to
XMLString at all. Do you have a call stack for this? Thx.
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: RE: Store String references
in XMLString
10/31/2002 04:07
PM
Please respond to
xerces-j-dev
see comments below
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:sandygao@;ca.ibm.com]
Sent: Thursday, October 31, 2002 1:43 PM
To: [EMAIL PROTECTED]
Subject: Re: Store String references in XMLString
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.
Actually I do clear the String, but as you mentioned below, I
didn't do a diff, mea culpa. Here's the diff for the clear:
public void setValues(char[] ch, int offset, int length) {
this.ch = ch;
this.offset = offset;
this.length = length;
this.string = null; // added line
}
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.
XMLString .toString() is being called as a result of
Element.getFirstChild().getNodeValue(); (Node.getNodeValue());
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.
Not sure about this, but will look into 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
True True.
> 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)?
I believe it does.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
