On 2017-05-19 06:16, Graeme Geldenhuys wrote:
On 2017-05-18 16:33, Reimar Grabowski wrote:
and JS is clearly not faster than FPC.
The JavaScript version runs very smooth on my system. There is no
framerate counter though, so I don't know how much faster.
http://jsdo.it/notch/dB1E
Again, what does that say about FPC generated binary performance.
I think javascript has been recently heavily improved since millions of
people are using javascript and work was done to make it faster, whereas
not so many millions of people use fpc.
Still this is all a good test case to find flaws/slow downs in fpc and
fix them.
IMO this is like a bug report that's not really a bug, as the code may
still be correct, just slow...
And IMO when someone finds an issue like this, a slow part of the RTL or
the compiler, it is a good thing not a bad thing because now is a chance
to find out where the issue is. Whereas if this had not been found or
reported it would have gone unnoticed.
It might even be just 2 procedures somewhere that are extremely slow,
but correct, in some unit..
Until someone profiles it... no one knows. Sorry, I'm not up to date on
the latest findings of this thread if anyone profiled it or not.
Again if it is an rtl issue, the solution is to swap in a faster rtl
unit or even a couple of procedures .. that are causing it to become
slow. Or it could be some while loop in the rtl or a for loop. Or a
concatenation that wasn't using a fast Copy(), or something that could
have used a buffer, but did it one by one instead.
But reporting and finding the issue, imo, is a good thing... even if you
currently find fpc binaries slow, at least you found something to fix!
:-)
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
