Hi Yang, Thanks for answering!
I only snapshot pure JS code (written in AMD form), and when the JS code needs node modules (built-in, native, JS only, etc), I feed it proxy objects (`new Proxy`). Here is how the code I snapshot looks like - https://gist.github.com/alexandrudima/bda598fbed179a581986b634cc94ab8d I am trying to implement what is described here[1] for VS Code (also an Electron app). Perhaps the main difference is that I can snapshot a huge amount of code, as we compile our code to AMD and I don't need to hack or do anything with node's require to stitch things up. I also wrote our own AMD loader, so I can do everything I need to in order to snapshot basically all of our code. I am running `mksnapshot start.js --startup_blob snapshot_blob.bin`. This creates a 40 MB `snapshot_blob.bin` file, which I use to overwrite the original 1.3 MB `snapshot_blob.bin` file that ships with Electron. The 40MB snapshot is effectively the entire VS Code application (except for node modules, for which the code has references to proxy objects). The file I am producing, snapshot_blob.bin, contains all the heap state after executing the code in start.js. The heap state includes all the AMD modules, with their exports, such as class definitions (functions with prototypes), all the other utility functions, statics, etc, which I can call and execute directly without loading any additional JS source code in the VM at runtime. Sorry for calling it "snapshotted code", but that's what I meant. My code is there, available, I don't need to load it, so it is a part of the snapshot... At runtime, when the application starts up, there is startup code (part of the snapshot too) which will begin to instantiate those classes (also part of the snapshot), will then proceed to look at what folder/files you have opened, what is the environment, what folder you have opened, etc. and eventually will "paint" by creating DOM nodes, etc... My problem is that these classes, which are captured in the snapshot, are significantly slower when I execute them, compared to when those same classes (same code) are loaded from source or from code caching. I was trying to capture this problem in my original screenshots. The "shell open" part of the two screenshots shows this problem. When loading code from source or from code caching, the JS profiler shows that everything is "squashed" into the `runCallback` method. When running the classes as they are captured in the snapshot, the JS profiler shows perhaps each and every function call. I have followed some of your tips from here [2], i.e. I tried running `mksnapshot --ignition --turbo start.js --startup_blob snapshot_blob.bin` I also tried running `mksnapshot --no-lazy start.js --startup_blob snapshot_blob.bin`. All of these tweaks resulted in varying sizes in the output `snapshot_blob.bin`, but the speed of the executing code was still slower. I am wondering if I am doing something silly (e.g. perhaps by using proxies, or if the v8 flags don't 100% match at runtime, should --ignition --turbo be there at runtime too ?) or is it expected that functions (code) included in a snapshot are slower than those loaded at runtime? Thank you again for your time, Alex [1] https://blog.atom.io/2017/04/18/improving-startup-time.html#v8-snapshots [2] https://github.com/nwjs/nw.js/issues/269#issuecomment-224490557 -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
