outcue / newspeak Goto Github PK

As far as I can tell, time is spent in class PrimordialFuel>>Snapshotter and PrimordialFuel>>Serializer, in the obvious places inside the serialization routines.

The same code is used to serialize things when running the C version.

If you run the build, this will include an invocation of WebCompiler under the C VM. WebCompiler will compile a bunch of stuff, read images from files etc. and serialize it all using PrimordialFuel>>Snapshotter. Even though it prints a ton of stuff to the terminal, it is still way faster than serializing in the IDE. Is this just WASM vs C performance? It shouldn't be, according to Ryan, who would tend to know such things. There is a gap, but it should not be dramatic.

So, why the difference? The IDE code that calls this is a variant of the WebCompiler code. Am I doing something stupid? Or is it something to do with the browser, or memory/heap settings? Also times vary a good deal - from very slow to super slow. Why?

To deploy in the IDE, you just pick an app (say TodoMVCApp) and click on deploy. Any GUI application will need RuntimeWithMirrorsForPrimordialSoup, which you get by choosing "As Victory Fuel With MIrrors".
You can compare to the C VM by running something like this in the newspeak/out directory

../../primordialsoup/out/ReleaseX64/primordialsoup
../../primordialsoup/out/snapshots/WebCompiler.vfuel
*.ns
*.png
CodeMirror/lib/codemirror.js
CodeMirror/addon/display/autorefresh.js
RuntimeWithMirrorsForPrimordialSoup TodoMVCApp TodoMVCApp.vfuel

In fact, there are other scenarios where things go bad - single stepping in the debugger being the main one. While there we know how to optimize it, it is possible there is something in common. Both are inherently heavy operations (the single stepping is interpreting byte codes in the Simulator, which is Newspeak code being interpreted by the VM, which is WASM byte code ...). Either the Newspeak-on-WASM interpreter isn't up to it (unlikely) or else something is stupid at the implementation level, or the environment has an issue. At first blush this looks like GC - but the VM GC is pretty solid, having been adapted from the Dart VM. In any case, this causes much spinning of fans and of beach balls of death, and takes intolerable amounts of time.