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

[Mark Waddingham]

Hi Herman,

This is all very useful information I must confess.

I guess I'm wary of just extrapolating potential performance from piecing together results from very different underlying architecture (e.g emterpreter vs no emterpreter) over bastions different html5 engine iterations.

Of course your post has made me wonder whether a hybrid approach might work (i.e. emterpret enough to get wait working but not so much it damages performance - I'm sure there was a technical reason why this wasn't an option - but it is probably worth trying again).

Also it might be worth doing two versions one wait capable (slow speed); one non-wait capable (faster speed).

At least then users have a choice and it will depend on their app which they need to use.
 
Anyway, I'm on holiday for a week now so might be a bit quiet on here (compared to recently, anyway). However I will return to this, and everything else when I'm back.

Warmest Regards,

Mark.

Sent from my iPhone

On 30 Jul 2017, at 19:25, hh via use-livecode <use-livecode at lists.runrev.com> wrote:

>> Mark wrote:
>> 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...
>> ...The only way to know what the speed of a certain combination of 
>> implementation strategies and execution environments is to actually run 
>> performance tests.
> 
> Well, I compare "scenarios", that is "target-platforms" and  LC versions
> that generate the standalone, running on "medium" hardware (mine, for tests).
> 
> May be some say I'm going to compare apples to oranges. Yes, I do, both are
> fruits and I can eat the one or the other or both. These are my experiences,
> without "wait":
> Say I'm on medium fast machines (2.5GHz), and say I am going to make an
> animation using graphics, with the fastest method (send in time, no wait) and
> everything needed is already available in LC 6.7.11.
> 
> Such scripts will run at about the same speed on desktop Mac/Win/linux (what
> is an excellent result).
> This is the base speed I keep in mind, it is at about the same for standalones
> or still being in the IDE.
> And this is probably one of the most used standalone version that is compared
> to HTML5 standalones, the latter built with "unchanged" source.
> 
> Now I will have here a slow down by a factor of (best cases)...
> ... 10 or 20 when running on Raspi2B+ or Raspi3.
> ... 2-3 when when running in LC 8/9 on the same machine.
> ... 6-32 when running in the newest version of the most used browser on
> Mac/Win/linux in a HTML5 standalone.
> 
> *** For me these are good-to-know thumb-rules, mostly very close to real tests.
> And running a test-stack on Raspi3 in the 6.5.1 IDE is at about the average
> speed I'll get in a HTML5 standalone on a medium fast machine with Mac/Win/linux.
> 
> Once again, compared to LC 8/9 desktop standalones, the slow down factor is...
> ... 3-16 when running in the newest version of the most used browser on
> Mac/Win/linux in a HTML5 standalone (what is an excellent result).
> 
> The lowest slowdown for HTML5 standalone is when using the 'fastest' browser of
> Safari/Firefox/Chrome/Opera which is currently Safari on Mac. For the 'slowest'
> browser (Chrome/Opera) there is AGAIN, compared to Safari, a slow down of 3-4.
> [-> But Opera Developer is already close to Safari!!]
> 
> In sum, if I wish to display a "complicated" clock animation every second (also
> having the different refresh rates of the different main browsers in mind) then
> I know I have to reach less than 30 millisecs per cycle in LC 6.7.11 or 60
> millisecs per cycle in LC 8/9. And I have to "work-around" for the worst case.
> 
> And if you wish to be below the refresh rate of 54 millisecs of Firefox on
> Mac/Win/linux with your HTML5 standalone, then you have to reach 5-6 millisecs
> per cycle in the LC 8/9 IDE on the same machine.
> 
> Such good results are in the dreams only of some other comparable IDE's.
> 
> So no exaggeration is needed. Take it as good as it is. And go on, LC-team, with
> your excellent work to improve it.
> 
> _______
> One possible "test-stack" to reproduce my thumb-rule statements on your own
> machine(s) is the source code of the "LCD"-HTML5 standalone.
> Start there with preset 7 for comparing browsers on the same machine:
> http://hh.on-rev.com/html5/LCD-01e-8.0.2X.html
> (replace "X.html" with ".zip" for the source)
> There is also Raspi stack #79 which is (probably) that source code
> http://forums.livecode.com/viewtopic.php?p=145528#p145528
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode