Understand performance of jsballs test

NEW
Unassigned

Status

()

Core
JavaScript Engine
9 years ago
4 years ago

People

(Reporter: dmandelin, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
See the URL. Here's some summary stats (The time left out of total is time outside of the JS engine):

Activity duration summary:

interpret    20513.672210
monitor       4992.706820
record         134.232200
compile        100.648830
execute       1260.539695
native         487.152210
-------------------------
Total        68462.286200
Estimated speedup:  0.32x

Reasons for transitions to interpret:
extend        9707.142795 ms   382592    25.372049 us
start         5808.678525 ms   112093    51.820172 us
extendOuter   2886.477385 ms    17267   167.167278 us
backoff       1724.791900 ms     5497   313.769674 us
abort          279.462860 ms      773   361.530220 us
cold            98.714645 ms      436   226.409736 us
extendOther      7.883900 ms     2572     3.065280 us
monitor          0.443885 ms      688     0.645182 us
stabilize        0.071485 ms        2    35.742500 us
extendInner      0.004830 ms        2     2.415000 us


I suspect we have several problems here, but the biggest is that we exit back to the interpreter a lot for the 'extend' reason. This means we took a BRANCH_EXIT but were unable to extend the tree at that point. In this case, that was almost always because we were at MAX_BRANCHES.

The loop that hits MAX_BRANCHES has its trace header at http://jsballs.com/fightjs.php:2083@251.

Here is a list of all the branch extensions we successfully started for this tree:

  38 exstart http://jsballs.com/fightjs.php:2086@269 tree http://jsballs.com/fightjs.php:2083@251
  40 exstart http://jsballs.com/fightjs.php:2086@272 tree http://jsballs.com/fightjs.php:2083@251
 101 exstart http://jsballs.com/fightjs.php:2086@283 tree http://jsballs.com/fightjs.php:2083@251
 106 exstart http://jsballs.com/fightjs.php:2086@284 tree http://jsballs.com/fightjs.php:2083@251
   5 exstart http://jsballs.com/fightjs.php:2086@288 tree http://jsballs.com/fightjs.php:2083@251
   1 exstart http://jsballs.com/fightjs.php:2321@135 tree http://jsballs.com/fightjs.php:2083@251
  56 exstart http://jsballs.com/fightjs.php:2482@147 tree http://jsballs.com/fightjs.php:2083@251

I'm not entirely sure why there are so many duplicates. It could be because we are flushing every now and then. It could also be that there is tail duplication going on here, which I guess would generally tend to happen in a lot of cases where MAX_BRANCHES gets hit.

I think the problem is a combination of many control flow paths through the loop and/or many properties being read from many shapes due to the object-oriented design.
Site is gone, you still have a copy?  MAX_BRANCHES sounds like profiling and JM will help us a lot, but!
dmandelin, is this the same thing?
http://www.uselesspickles.com/jsballs/
(Reporter)

Comment 3

7 years ago
(In reply to Ryan VanderMeulen from comment #2)
> dmandelin, is this the same thing?
> http://www.uselesspickles.com/jsballs/

Yes. It's still an interesting perf test. I checked to see if it has GC pauses but it seems not to.
Very smooth on my system as well. Retitling since this really isn't about a regression in performance at this point.
Summary: TM: mild performance regression on jsballs → Understand performance of jsballs test
(Assignee)

Updated

4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.