[TCLCORE] Re: Hintermayer's string allocation patch

[Dan K. <ku...@aj...>]

The initial problem from the newsgroup (from what I remember) was
that a user was planning on reading a large amount of data (from
a channel) into memory and wanted to know how much of his memory
tcl could use.  The response he got was 'amount of memory minus
some overhead' but when he wrote a test script using append he
found he could only use 128 K of his 256 K of memory.

This was because the tcl allocator was trying to double its
allocation whan a byte was appended to a 128K string and the
malloc would fail.  Currently when malloc fails in ckalloc
in tcl (the memory allocation wrapper) tcl will panic, because
the thought was that this means you have used all of your memory
and you can't really recover from the failure in a sane manor.

With the current allocation scheme this isn't true.  The greedy
allocation scheme works really well with small memory blocks
(it is more efficient to have less allocations), but as memory
grows large, you continue to double the space allocated.  This
means that if you are reading a lot of relatively large files
into memory using a fileevent and append, you are probably going
to waste a good chunk of memory with the current algorithm.

The intent of the patch was to do two things.  Make tcl more
memory efficient when the data in a variable is considered to
be 'big'.  This is a tunable that we need to find the right
size for.  Currently the old memory allocation schme is used
up to 1 MB but after that the new allocation algorithm is used.
The second change was to improve the performance of the
allocation by changing the allocation from a ckalloc to a 
ckrealloc.

In performance testing Eric found that simply using ckrealloc
instead of using ckalloc gave performance speedup across the
board.  Then when the new allocation algorithm was added
into the code, the times were the same for small allocations
and appends (as would be expected) and slower for doing
a series of large appends (as would be expected since in
this case, the new algorithm would start being used, and
the allocation would need to happend more frequently).

The net result of the two changes (the change to use ckrealloc
instead of ckalloc) and using the new memory allocation
algorithm was:

1.  Tcl is able to use a larger percentage of total memory
in *all* cases where strings over 1MB are built up using
append.  This is because the (new) allocation algorithm 
kicks in which is less greedy and more memory efficient.

2.  Tcl is faster in all append cases.  This is because the
change to using ckrealloc causes the code to be faster
than when ckalloc was used. There is speed up every where
append is done (even when it is done internal to the core).

It may make more sense to change the 'large string' size
from 1MB up to 4MB or so, but I am not sure.  I would
like it to be some size that is less than what the average
PC that is currently in use has.  I think that is probably
16 or 32MB (I am talking about common people, not corporate). 

I hope that helps.

--Dan

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.