commit c7d92fb7df4d81f124db10bb0a0989306484b250
author Henry Zongaro <zongaro@apache.org> Mon Apr 02 15:51:55 2007 +0000
committer Henry Zongaro <zongaro@apache.org> Mon Apr 02 15:51:55 2007 +0000
tree 4a67b40e180902a0eb95d2c26a5358ebe94777a2
parent fdc49d601b4911febfabc5d4d4b6f29a2c44ec2c

Part of fix for Jira issue XALANJ-2375.

Lexer.tokenize was always creating an OpMapVector object with large initial
sizes.  This was wasteful, because each XPath expression so tokenize might
need only a small amount of space.  Instead, changed the initial size to be
equal to five times the length of the string to be tokenized, just as a
very conservative estimate.  This has a significant impact on the performance
of the XPath API.

Reviewed by Christine Li (jycli () ca ! ibm ! com).

src/org/apache/xpath/compiler/Lexer.java

diff --git a/src/org/apache/xpath/compiler/Lexer.java b/src/org/apache/xpath/compiler/Lexer.java
index 55a492c..f185868 100644
--- a/src/org/apache/xpath/compiler/Lexer.java
+++ b/src/org/apache/xpath/compiler/Lexer.java
@@ -113,8 +113,15 @@
     m_compiler.m_currentPattern = pat;
     m_patternMapSize = 0; 
 
-    // This needs to grow too.
-    m_compiler.m_opMap = new OpMapVector(OpMap.MAXTOKENQUEUESIZE * 5, OpMap.BLOCKTOKENQUEUESIZE * 5, OpMap.MAPINDEX_LENGTH);
+    // This needs to grow too.  Use a conservative estimate that the OpMapVector
+    // needs about five time the length of the input path expression - to a
+    // maximum of MAXTOKENQUEUESIZE*5.  If the OpMapVector needs to grow, grow
+    // it freely (second argument to constructor).
+    int initTokQueueSize = ((pat.length() < OpMap.MAXTOKENQUEUESIZE)
+                                 ? pat.length() :  OpMap.MAXTOKENQUEUESIZE) * 5;
+    m_compiler.m_opMap = new OpMapVector(initTokQueueSize,
+                                         OpMap.BLOCKTOKENQUEUESIZE * 5,
+                                         OpMap.MAPINDEX_LENGTH);
 
     int nChars = pat.length();
     int startSubstring = -1;