[Freeciv-Dev] Re: (PR#7279) Macro optimizations

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >


Per I. Mathisen wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7279 >
> 
> On Tue, 20 Jan 2004, rwetmore@xxxxxxxxxxxx wrote:
> 
>>A lot of code is written as map_get_*(x,y) rather than caching the
>>map_get_tile() as ptile and calling a tile_get_*(ptile) function instead.
>>Some simple code changes in a few places here can reduce times significantly
>>as well.
> 
> Rafal tried this, and the result was not significant.
> 
>   - Per

In mapgen it was found to be quite significant. In general code, it resulted
in a few perecent speedup overall. If done correctly the results are somewhat
better than Rafael's experience. Thus you may want to expand rather than limit
your data points before making a final judgment.


The point to take home though is not that one should start a code purge to
optimize all existing code. Rather it should be to identify "best practices"
examples and guides for programming which provide clean efficient code. As
new code is written or existing code is patched, these practices can be used
instead of known poor ones and the perennial whine about it not mattering.
Over the long term it does matter as the Freeciv codebase dies the death of
1000 cuts.

A lot of code works within a tile context environment. Structuring code in
ways (aka through APIs) that provide access to data at the lowest level through
a tile pointer, with overloaded methods that first locate the tile, then work
through the tile interface means that the location step can often be optimized
either explicitly by the coder or implicitly by the optimizer to the top of a
code block. This should be recognized and adopted as a best practices technique.
Once significant amounts of code start to take on this structure, performance
gains will be seen.

By starting to think of code elements as objects within a layered hierarchy and
interfaces to access each level, one can spend a little bit of time insuring
each interface is coded efficiently, that it avoids spurious global references
or function calls that break optimizations, and that it isolates the actual
details of the implementation in each layer so that radical upgrades to a layer
are possible with little or no impact on calling code.

Such things can be done in "C" with Freeciv code over time. but only if
maintainers start taking the lead with a positive rather than defensive attitude
to understanding how to program effectively in "C", start thinking through the
issues in advance with full input from the community via the RFC route or some
equivalent process, and finally, start maintaining documentation and a strong
adherence to the technical merits of those decisions. This would be far more
productive than hiving off on faddish code purges or making radical changes to
established practices in backroom meetings based on the limited advice of
inexperience, while at the same time engaging in knee-jerk rejections of code
patches, ideas and review comments from the community at large.

Cheers,
RossW
=====