Wednesday, May 30, 2012

Dartium Snapshotting in Action (sort of)

‹prev | My Chain | next›

Last night I specially compiled a version of Dartium that can spapshot VM images of Dart applications. I am unsure what that actually means in practice, so tonight I am going to try to find out.

I start with the Speed Trace extension for Chrome / Chromium / Dartium. I used it to watch a fresh load of my Hipster MVC-based application: Dart Comics. Looking at browser events in Speed Tracer, I see:

I do not see anything obvious in that graph. The script evaluation is 50ms, but I am unsure if that includes Dart code or just Javascript (which is still required to kickstart the Dart VM).

Taking a look at the network events, I see the many Dart classes comprising my application and Hipster MVC being loaded:

So what happens if I reload the application? Does the script evaluation time go down because the VM is in cache?

In fact there is no change. If snapshotting is really in effect and Speed Tracer is including Dart evaluation in its calculation, then I ought to see a decrease. Regardless, the Speed Tracer extension is not going to be of any use to me since I can see the network information just as easily in Dartium's Developer Tools.

So what do I see when I do a reload?

Oooh! That is interesting. I see several 304 / Not Modifieds as the page, CSS, JS (starts the Dart engine), and main Dart script are reloaded. But the next resource loaded is the MVC framework loading my comic book collection—not the remainder of my application code being reloaded. Is that snapshotting in effect or does Dartium just always do that?

I still have the compiled Dartium available, so I load the application, then reload and see:

Ah, finally, snapshotting does have an effect. When enabled, Dartium checks the main.dart entry point. If it is unmodified, then Dartium does not even bother checking the remainder of the Dart code.

So does this caching linger between restarts? To answer, I close Dartium, start it back up and load Dart Comics:

Bummer. Dartium still loads all of the application resources even though main.dart is 304 / Not Modified.

Per a discussion on the mailing list, the snapshop enabled version of Dartium ought to honor a misnamed --enable-preparsed-js-caching command line switch for writing VMs to disk. Perhaps this will have an effect?

I start Dartium with said command line option:
➜  ~  ./repos/dartium/src/out/Release/chrome --enable-preparsed-js-caching
Then I load the application and close the browser. Hopefully this will write the VM to disk. I start Dartium, again with the --enable-preparsed-js-caching command line switch and load Dart Comics to see:

Aw well, it seems that snapshotting does not survive restarts. At least not yet. This is, after all, a disabled feature that needs special compilation options to enable. Presumably this will get more sophisticated over time.

What I would really like to see is actual VM files that can be loaded over HTTP for faster start up. Or better yet, pushed directly into browser cache with SPDY server push. That could be amazing.

Day #402


  1. Chris,

    to enable persistent snapshots, you need slightly tweak the code: in the very beginning of DartApplicationLoader.cpp file there is a function isSnapshottingEnabled which always return false. Change it to true, pass the flag and you should be set.

    We don't enable it by default due to various concerns. For example, Dart application consists of many parts. How we should treat the case when different files have different caching policies?

    1. Thanks, and thanks for getting me started a month back in the mailing list :)

      I enabled isSnapshottingEnabled the day before:

      The results in this post were with that `true` and did not seem to persist between browser restarts.

      Is there an actual .vm image file written somewhere or does it just get merged into the cache database? Are there any other behaviors that I might investigate with snapshotting enabled?