[Webkit-unassigned] [Bug 16202] Optimize allocation of ActivationImp objects

Sat Jan 5 04:45:30 PST 2008

http://bugs.webkit.org/show_bug.cgi?id=16202

cwzwarich at uwaterloo.ca changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18236|0                           |1
        is obsolete|                            |

------- Comment #11 from cwzwarich at uwaterloo.ca  2008-01-05 04:45 PDT -------
Created an attachment (id=18287)
 --> (http://bugs.webkit.org/attachment.cgi?id=18287&action=view)
Proposed patch

Here it is, passing all tests! I moved from a WTF::Deque data structure to an
explicit list of arrays of activation records, which exposed some bugs that
were not present before, most likely due to memory for each of the Deque
records not being reused by anything else after being freed. I think it's
pretty solid at this point. The JSC and layout tests contain a lot of the sort
of things that might trip up a patch like this.

Here are the Sunspider results:

TEST                   COMPARISON            FROM                 TO           
 DETAILS

=============================================================================

** TOTAL **:           1.044x as fast    3321.7ms +/- 0.2%   3180.5ms +/- 0.1% 
   significant

=============================================================================

  3d:                  1.014x as fast     401.2ms +/- 0.2%    395.8ms +/- 0.1% 
   significant
    cube:              1.013x as fast     135.6ms +/- 0.3%    133.9ms +/- 0.3% 
   significant
    morph:             *1.004x as slow*   132.4ms +/- 0.3%    132.9ms +/- 0.2% 
   significant
    raytrace:          1.033x as fast     133.2ms +/- 0.2%    129.0ms +/- 0.0% 
   significant

  access:              1.047x as fast     533.0ms +/- 0.3%    509.1ms +/- 0.1% 
   significant
    binary-trees:      1.162x as fast      78.2ms +/- 0.4%     67.3ms +/- 0.5% 
   significant
    fannkuch:          1.056x as fast     249.3ms +/- 0.3%    236.1ms +/- 0.1% 
   significant
    nbody:             -                  147.7ms +/- 0.2%    147.8ms +/- 0.2% 
    nsieve:            ??                  57.8ms +/- 0.8%     57.9ms +/- 0.4% 
   not conclusive: might be *1.002x as slow*

  bitops:              1.062x as fast     404.8ms +/- 0.4%    381.0ms +/- 0.1% 
   significant
    3bit-bits-in-byte: 1.101x as fast      81.5ms +/- 0.6%     74.0ms +/- 0.0% 
   significant
    bits-in-byte:      1.109x as fast     104.8ms +/- 0.3%     94.5ms +/- 0.4% 
   significant
    bitwise-and:       1.068x as fast     111.8ms +/- 1.1%    104.7ms +/- 0.3% 
   significant
    nsieve-bits:       *1.010x as slow*   106.7ms +/- 0.3%    107.8ms +/- 0.3% 
   significant

  controlflow:         1.25x as fast      111.8ms +/- 0.3%     89.5ms +/- 0.6% 
   significant
    recursive:         1.25x as fast      111.8ms +/- 0.3%     89.5ms +/- 0.6% 
   significant

  crypto:              1.088x as fast     263.5ms +/- 0.2%    242.2ms +/- 0.3% 
   significant
    aes:               1.006x as fast      80.2ms +/- 0.4%     79.7ms +/- 0.4% 
   significant
    md5:               1.144x as fast      92.7ms +/- 0.4%     81.0ms +/- 0.4% 
   significant
    sha1:              1.112x as fast      90.6ms +/- 0.4%     81.5ms +/- 0.5% 
   significant

  date:                1.026x as fast     291.3ms +/- 0.1%    284.0ms +/- 0.2% 
   significant
    format-tofte:      1.004x as fast     133.3ms +/- 0.3%    132.8ms +/- 0.3% 
   significant
    format-xparb:      1.045x as fast     158.0ms +/- 0.0%    151.2ms +/- 0.2% 
   significant

  math:                1.037x as fast     428.1ms +/- 0.3%    413.0ms +/- 0.2% 
   significant
    cordic:            1.025x as fast     172.0ms +/- 0.5%    167.8ms +/- 0.4% 
   significant
    partial-sums:      -                  163.2ms +/- 0.5%    162.8ms +/- 0.2% 
    spectral-norm:     1.127x as fast      92.9ms +/- 0.4%     82.4ms +/- 0.4% 
   significant

  regexp:              *1.060x as slow*   207.4ms +/- 0.2%    219.8ms +/- 0.4% 
   significant
    dna:               *1.060x as slow*   207.4ms +/- 0.2%    219.8ms +/- 0.4% 
   significant

  string:              1.053x as fast     680.6ms +/- 0.2%    646.1ms +/- 0.2% 
   significant
    base64:            1.016x as fast      99.3ms +/- 0.6%     97.7ms +/- 0.5% 
   significant
    fasta:             1.039x as fast     172.5ms +/- 0.5%    166.0ms +/- 0.3% 
   significant
    tagcloud:          1.067x as fast     146.5ms +/- 0.5%    137.3ms +/- 0.3% 
   significant
    unpack-code:       1.090x as fast     150.9ms +/- 0.3%    138.5ms +/- 0.3% 
   significant
    validate-input:    1.045x as fast     111.4ms +/- 1.1%    106.6ms +/- 0.8% 
   significant

As you can see, it's a nice improvement across the board and an even better
improvement on benchmarks that use a lot of function calls. The only test that
is slightly mysterious is the regexp-dna test, because it doesn't have any user
functions and thus shouldn't be getting a significant hit. It might be a code
layout issue.

The one thing I didn't do was attempt to annotate the syntax tree so that many
cases of tear-off could be avoided by simply allocating the activation record
on the JS heap in the first place. This might give a slight performance
improvement.

I didn't even bother including a ChangeLog at this point, because I know the
style police are going to be all over me with this one. I apologize in advance
if there is anything particularly bad in the code, but it is difficult to do
some of the things in the patch in a completely clean way.

I know a lot of people, myself included, want to see this landed soon, so I
will try to be extremely responsive to any comments and suggestions from
reviewers. Hopefully, we can get a final version in a few days.

-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.