JS speed - Konq vs. Mozilla

[Koos Vriezen]

Hi,

I have a few benchmarks done with the for-loop bench (0 to 10000) on a P4:
Current CVS:
real    0m1.011s
user    0m1.000s
sys     0m0.010s
real    0m1.008s
user    0m1.010s
sys     0m0.000s

My yesterday patch (with slightly optimized CollectorBlock::free)
real    0m0.905s
user    0m0.880s
sys     0m0.010s
real    0m0.908s
user    0m0.900s
sys     0m0.010s

Looking for why BlockIterator::next is called that often, I stumbled on
collector.cpp:68 (current CVS):
  if (filled >= softLimit) {
    timesFilled++;
    collect();

    if (filled >= softLimit && softLimit < KJS_MEM_LIMIT) {
      // Even after collection we are still using more than the limit, so increase
      // the limit
      softLimit *= 2;
    }
    else if (timesFilled == increaseLimitAt && increaseLimitAt < 128) {
      // The allowed memory limit keeps getting reached (lots of objects created
      // and deleted). Increase it a bit so GC gets run less often.
      timesFilled = 0;
      softLimit *= 2;
      increaseLimitAt *= 2;
    }
  }
Putting printf's around the first 'softLimit *= 2;' statement, I noticed
that filled always reduced to about 180 (softLimit being 1000 at first).
Despite that, the 'else if (timesFilled.....)' evaluate 'true' after each
second 'collect()' call. I think that is wrong, more blocks makes
allocating slower, collecting a lot slower and uses gradually more memory.
Commenting it out, results as follow.
Current CVS:
real    0m0.901s
user    0m0.880s
sys     0m0.010s
real    0m0.901s
user    0m0.890s
sys     0m0.020s
My yesterday patch (..)
real    0m0.834s
user    0m0.830s
sys     0m0.000s
real    0m0.831s
user    0m0.830s
sys     0m0.000s

So why run the GC less often if collect() frees enough memory? Why not:
  collect();
  if (softLimit/(filled+1) < 2) // still more than half full
    softLimit *= 1.4; //golden egg ratio

and don't let softLimit grow so much (ended with 32000 in this bench).

Koos