Wait, the problem, and why it is important to solve
hh at hyperhh.de
Sun Jul 30 20:25:57 CEST 2017
> 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,
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:
(replace "X.html" with ".zip" for the source)
There is also Raspi stack #79 which is (probably) that source code
More information about the use-livecode