[fpc-pascal] FPC Graphics options?

noreply at z505.com noreply at z505.com
Tue May 23 00:07:05 CEST 2017


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! 
:-)



More information about the fpc-pascal mailing list