Hi All,
Sorry for not get back to you right the way. Tom, you are right, I had ran
some testing against the performance vs memory usage, and concluded that it
did required much more memory than the original one, I also found 2 careless
mistake in my code as well... sorry for the bugey code...:-(
That's why I didn't get back to you all since I go ahead and re-design a
better string class based on the previous one. This time I keep in mind both
performance issue and memory usage. And there we go.. after serious of
performance testings, it indicated that this improved version is about 30%
to 43% faster than the original one, and required 5% to 15% LESS memory....
Here is some testing result on my own computer:
Average of 3 runs testing on a Pentimum III 366MHz with 192MB of memory. The
test is using one of our own style sheet which convert the XML document into
HTML using various xsl statements, and the result are as follows:
orig time orig mem
new time new mem
large-test.xml (301K) 1.77s 4.61M
1.05s 4.34M
large-test2.xml (601K) 6.00s 10.08M
3.51s 9.01M
large-test3.xml (1.2M) 28.32s 30.81M
16.43s 30.03M
larget-test4.xml (2.4M) 118.80s 101.43M
68.05s 94.95M
It's about 43% faster with 5% less memory...;-)
I also ran a full test suite which I got it from my colleague, the results
are 30% faster and 15% LESS memory on average. The results are listed in the
attached excel document.
I wonder whether you gents/ladies have any benchmark testing suite that will
help me to confirm the result... It will be extremely appreciated if you can
run some testing for me such that the result are more generalize in terms of
system configuration.
For anyone who is interested in the changes, here is brief explanation of
the new string class:
Each string object will have a char array of size 32 bytes. If
append/assignment caused an overflow, then a dynamic allocated buffer will
be used... The size of the dynamic allocated buffer will start at 64 bytes,
and the size will be double (until large enough to hold the overflow string)
when an overflow occurs.
Here are the file changed, all changes are currently within the compile
defined "#ifdef FAST_STRING"... so you have to add this new macro in your
Makefile.
Thanks in advance for all you help.
William.
-----Original Message-----
From: Kaiserovi [mailto:[EMAIL PROTECTED]]
Sent: October 3, 2000 5:27 AM
To: Sablotron Mailing List
Subject: Re: [Sab] FW: Sablotron Performance...
William,
thanks for the idea. But I'd expect memory demands to rise
considerably, could you give some details on that? Does the 20% speed
gain pay off? The current Str handling is sort of the best time-space
compromise we managed to find. In particular, we tried to reduce the
load on the heap manager by implementing a memory arena where the
strings reside, which has helped a lot.
Tom Kaiser
> "Lee, William" wrote:
>
> Hi there,
>
> I'm working with the Sablotron 0.44 performance... and found out that
> most of the time it is spending on allocating little trunk of memory
> for small string and for appending small strings...
>
> To speed up the performance in this area, I have implement a new
> string class, which replaced both existing DStr and Str classes. The
> idea is as follows:
>
> Each Str object will now contains a pre-allocated buffer of size 1K
> (customizable in the source code, but 1K is the optimal so far to
> avoid stack overflow)... Any string assignment/append with work with
> this buffer unless it caused an overflow, and in that case, a dynamic
> allocated buffer will be used. The size of the dynamic allocated
> buffer is round up to the nearest 4K (again, customizable in the
> source code), and again, any string concatenation will be done within
> the same buffer, and will be "reallocated" to a bigger size when a
> bigger one is need.
>
> I have run some performance testing against the release/optimized
> version, and the result are:
> a small one (xml ~90K and xsl ~80K) which took 1050ms before
> is now takes only 800ms
> a medium size one (xml ~ 300K and xsl ~80K) improved from
> 2200ms to 1800 ms
> (i.e., the average is around 20% improvement).
>
> Since I'm new to this mailing list, could anyone let me know what is
> the procedure/steps to follows for this kind of changes? Or how can I
> submit the changes in order to get accepted/approved by the group?
>
> Also, I believed the following is a bug in datastr.cpp:
>
> int Str::compare(const char* otherChars) const
> {
> return (strcmp(operator char*(), otherChars) < 0);
> }
>
> which I believed it should be:
>
> int Str::compare(const char* otherChars) const
> {
> return (strcmp(operator char*(), otherChars));
> }
>
> Thanks in advance for your help.
> William Lee
>
> Name: datastr.cpp
> datastr.cpp Type: Emacs File
> (application/x-unknown-content-type-cppfile)
> Encoding: quoted-printable
>
> Name: datastr.h
> datastr.h Type: C Header file
> (application/x-unknown-content-type-hfile)
> Encoding: quoted-printable
arena.h
datastr.cpp
datastr.h
test.xls
