[fpc-devel] Patch for rtl/inc/rtti.inc

Daniël Mantione daniel.mantione at freepascal.org
Sun Sep 14 19:00:41 CEST 2008



Op Sun, 14 Sep 2008, schreef Jonas Maebe:

>
> On 14 Sep 2008, at 15:11, Daniël Mantione wrote:
>
>> Op Sun, 14 Sep 2008, schreef Jonas Maebe:
>> 
>>> I don't think it's a good idea to start manually adding loop induction 
>>> variables to many routines in the rtl. It makes the code less 
>>> maintainable, and at one point the compilation process itself will/should 
>>> do that by itself.
>> 
>> This patch should get applied. It's debatable wether additions are hard to 
>> maintain than multiplications
>
> Having one or two variables that need manual updating in a loop vs none at 
> all reduces maintainability. It's one of the reasons why people use for-loops 
> rather than while-loops.

While I don't disagree, it's debatable, because it solves another 
maintainability issue: A simple procedure call is more maintainable than 
one with all kinds of expressions inside.

>> and it may take years before the compiler can do that optimization. That 
>> doesn't mean we should optimize anything manually, but fpc_copy is 
>> definately speed critical code for things like widestrings.
>
> Almost every loop in the RTL is criticial for at least one language feature 
> which is heavily used by a certain category of programs.

You are completely correct here, this is why a lot of effort goes into 
optimizing the system unit, it is one of the most speed critical hotspots.

Anyway, this should be viewed from an engineering point of view: 
Maintainability is no goal by itself, nor is speed, good engineering 
balances both requirement. Recklessly rejecting patches is wrong, because 
someone may have important interrests in having that code fast. The right 
approach, if you are concerned about maintenance is ask the user to show 
speed has to have more interrests here, for example ask the user to show a 
real-world situation where these routines show up high in a profile. But 
we don't need to here, since we can see the speed interrests here 
ourselves and the maintainability issues are minor.

Daniël


More information about the fpc-devel mailing list