fillchar is one useful function, but should be avoided from use in time critical code by any cost. Only reasonable way to improve fillchar is to make it internal function, where fpc can decide, depending on parameters, what will be best solution for filling mem with specified value. But it will also slow down compilation time. Not sure fpc core team will accept that kind improvement.
Optimized code for speed most likely became less readable and less maintainable. It's misfortune of optimization. ----- Reply to message ----- Subject: Re: [fpc-devel] I'll be straight Date: 2019. gada 9. februāris 10:35:51 From: J. Gareth Moreton <gar...@moreton-family.com> To: FPC developers' list <fpc-devel@lists.freepascal.org> > Thanks Michael, > In the last patch that Jonas almost immediately closed, the speed savings were inconclusive because the number of cycles saved is probably only a few dozen, but I would argue it makes the code a bit more reasonable too because it replaces things like loc[low(loc)] with loc[0] and fillchar with a for-loop that initialises each element of an array to zero (it's slightly faster because the element size is a multiple of 16, while fillchar is general-purpose and spends a lot of time jumping around and even performing a multiplication before it starts filling things up). I guess seeing it marked as "won't fix" within 20 minutes was a moment of horror. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
