RE: Lua 5.1 (work0) -- 1st torture test

["Joshua Jensen" <jjensen@...>]

> > Using Subversion, grab the ref counting Lua 5.0.2 I have at:
> > 
> > svn co svn://24.2.105.59/root/luarc
> > 
> > I'm running on a 2.8 ghz HT Intel box, and the results I get are 
> > (memory reported by the Windows Task Manager):
> > 
> > Lua 5.0.2: at n =  200000   time =         23.968   Mem Usage 
> > 2588 K / VM
> > 1972 K
> > Lua 5.1w0: at n =  200000   time =         23.64    Mem Usage 
> > 3580 K / VM
> > 2580 K
> > luarc:     at n =  200000   time =         11.546   Mem Usage 
> > 1800 K / VM
> > 1168 K
> 
> More performance numbers... I could only stand to wait for n 
> = 800000, so that's as far as they go.  Note, Mem Usage == 
> physical RAM and VM == virtual memory.  So, in the Lua 5.0.2 
> case below, memory peaked at 124,500 megabytes.
> 
> Lua 5.0.2: at n =  800000   time =         1017.218  Mem 
> Usage 63000 K /
> 61500 K VM
> Lua 5.1w0: at n =  800000   time =         1030.421  Mem 
> Usage 46456 K /
> 45260 K VM
> luarc:     at n =  800000   time =         892.343   Mem 
> Usage 5372 K / 5096
> K VM

One more, and then I'm done.  340 seconds can be gained for all
implementations (in the n=800000 case) if the luaV_concat algorithm is
changed.  Memory is saved, too (1.5 megs in the luarc case... I didn't
bother running it for the other cases...).  Instead of writing the
concatenated string into an auxiliary buffer, a new TString is created and
the memory is copied directly there.  After the copy is done, the hash is
generated on that buffer, and if it matches an existing TString, it is
freed.  Otherwise, the TString is kept.

Just a thought for an optimization... for the n=200000 case, the luarc
timing is 4.312 seconds instead of 11.546 seconds...

Josh