The following issue has been updated:
Updater: Brian Minchau (mailto:[EMAIL PROTECTED])
Date: Tue, 7 Sep 2004 1:51 PM
Changes:
type changed from Bug to Improvement
priority changed from Blocker to Minor
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/XALANJ-19?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/XALANJ-19
Here is an overview of the issue:
---------------------------------------------------------------------
Key: XALANJ-19
Summary: Request for performance enhancement to contains() function
Type: Improvement
Status: Unassigned
Priority: Minor
Project: XalanJ2
Components:
XPath function
Versions:
2.0.0
Assignee:
Reporter: Scott Boag
Created: Thu, 1 Mar 2001 1:08 PM
Updated: Tue, 7 Sep 2004 1:51 PM
Environment: Operating System: Other
Platform: Other
Description:
hrister, how big are the strings that contains() is using?
What we do is normally store the text memory for characters in a single string
buffer. But when you use a string function such as contains, the data from
contained nodes have to be concatinated into a string, so we can use the java
indexOf function. We could optimize this for this particular case by simply
doing the contains operation directly on the character array, since the
characters should be in proper sequence. This holds true for many of the
string oriented functions. I don't think we can do this in time for the 2.0.0
release though... it will have to wait for 2.0.1.
But since there is nobody holding on to the arguments, I'm surprised you're
running out of memory. The strings that are created should be garbage
collected.
Hmm... but I notice that if the node argument is a Text node directly, the
node's getData function will be called, which will cause the string to be
cached in the node. I'm loath to change this right now, because it could
increase the number of Strings being created overall... but let me think about
it a bit.
-scott
"Christer
Evenius"
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: XPath - OutOfMemory
01/22/2001 07:19
AM
Hi, everyone!
Xalan Release: 2.0.D07
I'm doing some performence testing on large xml documents ( > 50000 elements ).
When I use the XPathAPI with the contains() function to find a certain element,
my JVM runs of out space!
The document is stored as DOM-elements in a Versant object database so the
document in it self will not consume that much memory. When fetching elements
with other xpath functions e.g. position() it works fine so I guess the contains
() function uses some kind of internal buffering that makes it impossible for
the garbage collector to clean up.
Does anyone have a clue what this is about, is it a bug or...
Regards
Christer
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
