jkesselm 01/03/23 10:23:24
Modified: java/src/org/apache/xml/utils FastStringBuffer.java
Log:
reset() versus setLength(0).
Revision Changes Path
1.10 +14 -1
xml-xalan/java/src/org/apache/xml/utils/FastStringBuffer.java
Index: FastStringBuffer.java
===================================================================
RCS file:
/home/cvs/xml-xalan/java/src/org/apache/xml/utils/FastStringBuffer.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- FastStringBuffer.java 2001/03/23 00:00:32 1.9
+++ FastStringBuffer.java 2001/03/23 18:23:22 1.10
@@ -241,7 +241,9 @@
}
/**
- * Discard the content of the FastStringBuffer.
+ * Discard the content of the FastStringBuffer, and most of the memory
+ * that was allocated by it, restoring the initial state. Note that this
+ * may eventually be different from setLength(0), which see.
*/
public final void reset()
{
@@ -258,6 +260,9 @@
// Discard the hierarchy
m_innerFSB = null;
+
+ m_array=new char[16][0];
+ m_array[0]=new char[m_chunkSize];
}
/**
@@ -268,6 +273,14 @@
* if additional storage does exist, its contents are unpredictable.
* The only safe use for our setLength() is to truncate the
FastStringBuffer
* to a shorter string.
+ * <p>
+ * TODO: Current setLength code is probably not the best solution.
+ * It releases memory that in theory we shouldn retain and
+ * reuse. Holding onto that would require recursive truncation of
+ * the inner FSB, and extending the append operations to recurse
+ * into the inner FSB when space exists within them. Could be done,
+ * but nontrivial change and adds some overhead to the append
+ * operation. Consider alternatives. *****
*
* @param l New length. If l<0 or l>=getLength(), this operation will
* not report an error but future operations will almost certainly fail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
