HTML5 update: why it is slow?

[Peter TB Brett]

Hi all,

We've had experimental HTML5 deployment available in several "Developer 
Preview" releases of LiveCode 8 so far, and I thought you might like an 
update on the status of the HTML5 engine and our current plans for it.

Recent changes
--------------

The most recent work that Fraser and I have done on HTML5 deployment has 
been:

* Adding deployment from LiveCode Business edition and LiveCode Indy edition

* Improving font metrics and rendering

* Enabling support for "wait" syntax -- as part of this work, the HTML5 
engine got a lot slower (see below)

* Enabling logging to standard output and standard error

* Porting our testsuite to (mostly) run in a browser

Current plans
-------------

Before LiveCode 8.0.0 is released, I hope that I can:

* Make the HTML5 engine faster again

* Make most "url" chunk syntax work

Once those two things are complete, then I plan to discuss with the 
people who are using the HTML5 deployment and see what issues are most 
affecting them in order to decide what to do next!

Why is the engine so slow since 8.0.0 DP 11?
--------------------------------------------

As you may know, we use the Emscripten C++-to-JavaScript to compile the 
LiveCode engine so that it runs in a web browser.  One of the 
interesting things about JavaScript is that functions aren't allowed to 
block, i.e. stop running and wait for something to happen.  In LiveCode, 
and in C++, this is very common!  For example, if you write:

     get url "https://livecode.com/"
     put the number of lines in it

Then you know that the first line will make LiveCode stop and wait until 
all of the data of our home page has been received over the network, 
which might take quite a long time.

To get around this, we use a technology called Emterpreter, which is 
part of the Emscripten compiler.  Normally, the engine C++ code is 
compiled to a specially optimised dialect of JavaScript called "asm.js", 
which can be run directly (and very quickly) by a web browser.  When a 
C++ function is compiled with Emterpreter, however, it compiles to a 
special bytecode that's run by a bytecode interpreter written in JavaScript.

Emterpreter helps get around the "blocking" problem because the bytecode 
interpreter can save the state of the program and quit.  Later, when 
something happens, it can load up the previously saved program state and 
start running it again.  However, every function that can block -- and 
every function that can possibly call a function that blocks -- must be 
compiled with Emterpreter.  Also, the bytecode interpreter is up to 22x 
slower than running asm.js code.

To make "wait" syntax work, I had to compile most of the LiveCode script 
evaluator using Emterpreter instead of compiling it to asm.js.  Needless 
to say, this makes running *any* script much slower!

Currently, Mark Waddingham and I are trying to figure out if it's 
possible to put *both* versions of the engine functions into the HTML5 
engine -- the slow, "wait"-compatible version, and the fast asm.js 
version.  Needless to say, this will make the engine source file (even) 
bigger, but on the other hand, it would provide an engine that both 
supports "wait" (and, importantly, "url" chunks) while also running code 
that doesn't need to block nice and quickly.

It remains to be seen whether I can figure out how do that. ;-)

                                         Peter

-- 
Dr Peter Brett <peter.brett at livecode.com>
LiveCode Open Source Team