Wait, the problem, and why it is important to solve

[Mark Waddingham]

On 2017-07-30 11:13, hh via use-livecode wrote:
> Wow. You say (using stars) it would make sense to implement wait
> in HTML5 for some features that do _not_ (yet) work in HTML5.
> Will be a great enhancement side-effect. I look forward to that.

I don't think that was the implication. The implication was that those 
things marked '*' all make sense in HTML5 - i.e. they actually *could* 
be implemented (the other things are mainly mobile related things which 
make no sense). The further point I made was that *all* of them are 
useful (if not identical) if wait does not work.

i.e. We get a more effective HTML5 engine by implementing them even if 
we don't have wait.

Ergo, the HTML5 engine gets even better when we do have wait - in terms 
of ability to use code without modification.

> Peter-B already implemented wait in 2015, see bug #16076.
> This caused an _additional_ slow down by a factor of 16 that was
> *overall*, i.e. also in handlers not containing any form of wait.

Indeed - hence the paragraph in one of my previous emails where I 
stated:

"The alternative - emterpreter - works perfectly but (as anyone who used 
the early wait-supporting versions will know) is waaaaaaaaaaaay too slow 
to be viable. Not an ideal situation, to say the least."

Emterpreter (due to the way things are structured in the C++ engine) is 
an all or nothing thing. It makes little difference whether things call 
wait or not.

Also to actually determine this 'calls wait' / 'doesn't call wait' 
attribute requires a level of abstract analysis of script which would 
essentially mean we were performing asyncification anyway. So that is 
what we might as well do, and not pay the cost of emterpretation at all.

> We had since then, not counting browser improvements, a speed up
> in the HTML5 engine by a factor of up to 8. So "wait" would cause
> in sum (better: in product) a slowdown by a factor of at least 2.

Well, compared to now perhaps.

I'd be wary of using such 'approximation' math on things like this. Just 
because we have numbers for certain combinations, it does not mean you 
can just recombine them with other assumptions (we don't know that the 
actual performance metrics can be added or multiplied either 
associatively or distributively).

The only way to know what the speed of a certain combination of 
implementation strategies and execution environments is to actually run 
performance tests.

> This is at about the same factor as with RaspberryPiB. RaspberryPi3
> has a slow down factor of at about 10.

I'm not sure relating this to RaspPi is useful. The reason is that if I 
am wanting to move my Desktop app (Mac, Windows, Linux) app to HTML5 
then I'd want the performance in the browser to be within a reasonable 
distance of that when on the Desktop.

Comparing different platforms (which are slower due to hardware 
implementation - slower memory buses, in particular) isn't all that 
helpful in determining the veracity of the HTML5 engine's performance.

> So the move of the HTML5 engine to WebAssembly may be a necessary
> condition?

WASM will likely make a significant difference to size and startup time. 
Performance, is probably more going to be in the 10-15% range. However, 
that is not a number to be relied upon. The only way to find out is to 
test and benchmark.

All I'm really saying, speculating based on the numbers we have, or 
against other (completely different) platforms isn't going to give us 
much, if any insight. The only thing we can do is try, measure and 
iterate. Then try, measure and iterate again.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps