JS speed - Konq vs. Mozilla

[Koos Vriezen]

On Fri, 6 Sep 2002, David Faure wrote:

> On Thursday 05 September 2002 22:31, Koos Vriezen wrote:
> > Couldn't resist trying to merge not fully fulled blocks, because it still
> > can happen (is even likely) that the number of blocks only grows in time.
> > It also sqeezes another 2% speed gain out of the bench (tested with 0 to
> > 5000).
>
> Hmm, this one confuses me a bit. Can you add comments to the code? :}
>
> (You mention merging, but I see no merging of existing blocks in the code,
> AFAICS this would require some copying things around...)

The CollectorBlock 'nonfull' is always the first not fully filled block
before the current in this '2nd step' scan, or NULL if all block seen are
either full or empty. All non-freed slots are copied to 'nonfull' block,
to an empty slot at the beginning of this block (if 'nonfull' is NULL) or
not copied (if 'nonfull' is NULL and all slots before the current are
full).
The bench, iterating from 0 to 5000, current CVS 2x:
real    0m5.070s
user    0m4.930s
sys     0m0.030s
real    0m5.041s
user    0m4.870s
sys     0m0.050s
After this patch:
real    0m4.832s
user    0m4.710s
sys     0m0.010s
real    0m4.857s
user    0m4.680s
sys     0m0.030s
If I change it, so that 'nonfull' doesn't skip empty blocks (removing
'|| nonfull->filled == 0' from the test (two places), the last scan
(deleting empty blocks) can start with 'nonfull' or last scanned block (if
'nonfull' is NULL). No speed gain here, probably more copying.

Remains the question, why is it faster? Current CVS, tens/hundreds of
blocks will be partial filled. Moving the currentBlock to the next
partial filled, must be the speed impact (but I'm not sure, because the
bench only have a few blocks).
With this patch currentBlock is always the last block.

Btw, I think I'll change '*(block->mem + freespot) = imp' to
'block->mem[freespot] = imp' for readability.

Regards,

Koos