Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: Fixed
User never visited
Closed: Sep 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment
Large generated code blocks stutter in the first few seconds of execution
Reported by, Apr 17 2012 Back to list
Chrome Version       : 18.0.1025.162 m
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :

Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: not tested
  Firefox 4.x: OK (fps rate slightly slower in first few seconds)
     IE 7/8/9: not tested
Opera Next 12.00 alpha: almost OK (slight stuttering throughout the demo)

What steps will reproduce the problem?
1. start webgl demo given in URL

What is the expected result?
should run smooth (or slightly lower fps rate due to background jit compiling)

What happens instead?
stuttering at the beginning of every new part 

Please provide any additional information below. Attach a screenshot if
every part of the webgl demo consists of a large generated chunk of javascript code.
screenshot available here:

Labels: -Area-Undefined Area-Internals Feature-GPU-WebGL
Comment 2 by, Apr 27 2012
Labels: -OS-Windows OS-All
Status: Available
CC'ing some members of the V8 team.

The above demo reproduces a multi-second pause soon after it begins animating which isn't GC. Immediately after this long pause occurs, the following is printed to the console:

   52179 ms: Mark-sweep 13.3 (30.8) -> 3.6 (23.4) MB, 3 / 31 ms [allocation failure] [GC in old space requested].

My best guess is that the long pause is compilation. Is there a V8 flag to print high-level information about compiles (what was compiled, how long the compilation took, etc.)? I tried --log_all but don't see any code events.

Reproduced locally on MacBook Pro, 10.6.8, NVIDIA GeForce GT 330M GPU, Chrome 20.0.1118.0 (Official Build 134058) canary.

If this should be filed elsewhere (e.g. in the V8 issue tracker) please go ahead and create the bug, closing this if desired or necessary.

Comment 3 by, Apr 30 2012
Running with the --trace_opt flag outputs which functions were compiled with the optimizing compiler and how long it took.

It looks like optimization of the "instance.update()" function is causing the pause:

[marking instance.update 0x49a757dc for recompilation, reason: hot and stable, ICs with typeinfo: 3307/3911 (84%)]
[marking radiotherapy.scenes.intro.render_k_0 0x49a1b6a8 for recompilation, reason: hot and stable, ICs with typeinfo: 214/216 (99%)]
[marking radiotherapy.scenes.intro.render_p_0 0x49a1b75c for recompilation, reason: hot and stable, ICs with typeinfo: 214/216 (99%)]
[optimizing: instance.update / 49a757dd - took 2153.766 ms]
[optimizing: radiotherapy.scenes.intro.render_k_0 / 49a1b6a9 - took 2.307 ms]
[optimizing: radiotherapy.scenes.intro.render_p_0 / 49a1b75d - took 2.786 ms]
   54359 ms: Mark-sweep 13.1 (30.9) -> 4.1 (22.4) MB, 33 ms [Runtime::PerformGC] [promotion limit reached].

The function is quite big (about 2000 lines of code). I'll post more if I manage to run it as a standalone script in v8 shell and profile its compilation.
39.4 KB View Download
Comment 4 by, Apr 30 2012
Thanks for the analysis. Based on what little I know of Jochen's compilation strategy, it isn't surprising that the "update" method is huge. Essentially, he compiles scenes from the 3D modeling software package Maya, including their animations and behavior, into one massive JavaScript function. In order to display the model each frame, he modifies some parameters and calls "update" on each model in order to have it update its state for rendering. This is a very different strategy than many other exporting tools which target a game engine or scene graph and update multiple small nodes each frame.

Comment 5 by, May 7 2012
I think there is a trick that can be used to improve compilation speed, although it's not very elegant and I am not 100% sure this is what is going on and how much it will help, it's just from inspecting the code. With so many local variables, I suspect a good chunk of time is spent in the regster allocator. If instead of creating new variables or each intermediate results, like aa, ba, bc, etc., you can use "new Array()" to create an array at the beginning of the function that is large enough to hold all the intermediate results and assign a unique index to each intermediate value. Array loads and stores to this array will not create so many live ranges inside the function and speed up register allocation by reducing live rangers, and will only be slightly slower during execution.

In any case, we'll look at why the compilation is taking so long.
Comment 6 by, May 7 2012
Status: Assigned
Comment 7 by, May 17 2012
See V8 bug regarding a likely similar problem, but seen with Emscripten-compiled code.

Comment 8 by, May 21 2012
Comment 9 by, Sep 26 2012
Status: Fixed
Fixed in v8:r12613.
Project Member Comment 10 by, Mar 10 2013
Labels: -Area-Internals -Feature-GPU-WebGL Cr-Internals-GPU-WebGL Cr-Internals
Project Member Comment 11 by, Apr 10 2013
Labels: -Cr-Internals-GPU-WebGL Cr-Blink-WebGL
Sign in to add a comment