Adam Heath wrote:
Adrian Crum wrote:
That's it. If you want to know how this will benefit memory use, read on...
Consider this mini-language statement:
<set field="isTrue" value="Y"/>
The value attribute is kept in memory as a FlexibleStringExpander
instance. That instance will contain one instance of ConstElem that
contains the String "Y". So, let's tally up the memory used for this
single character:
FlexibleStringExpander fields:
String orig = "Y"
List strElems = a List with one ConstElem element
int hint = 20 (used as a StringBuilder initial size)
ArrayList has the internal array, which has a default size of 20, you
are correct. However, that's not the only field. There is an 'int
size' and 'int modCount'.
ConstElem fields:
String str = "Y"
That's a lot of overhead to store a single character. After the proposed
refactor, the value attribute will be kept in memory as a ConstElem
instance - which will contain nothing more than the String "Y".
The ConstElem class really doesn't need the String class methods, so we
can eliminate the String instance too - by storing it as a character
array. Now the "Y" StringExpression instance takes up the same space as
a String object.
The embed String meanwhile has an 'int hash', 'int count', 'int
offset' field, in addition to the 'char[] value' array.
The point I was trying to make is: We can have an expression evaluator
for the same cost as a String. If it costs less than s String, then so
much the better.
