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 ~ [email protected] ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
