On 15.12.2010 02:30, Stefan Fuhrmann wrote:
> On 14.12.2010 23:35, Johan Corveleyn wrote:
>> Some considerations:
>> - Maybe I can use APR_INLINE, with similar results?
>>
>> - Maybe I can put just the "critical section" into a macro (the curp++
>> / curp-- part), and call a function when a chunk boundary is
>> encountered (~ once every 131072 iterations (chunks are 128 Kb
>> large)), to read in the new chunk, advancing variables, ...
> Prefer inlining because the compiler is free to ignore it.
> Depending on the target architecture and the compiler,
> it may be beneficial to "narrow" the scope of optimization:
> In large functions, the optimizer may guess wrongly about
> the hot spots.
Certainly. These days it makes no sense to use macros instead of
inlining, except in really, really extreme cases (of which there should
be none in Subversion code), or where macros are used for tricks that
the language proper doesn't support (debug-mode error location reporting
being such an example).
Which raises the question -- did you run your test case with a
fully-optimized build, or with some debug-friendly build? Compilers
these days /should/ be able to automatically inline static functions,
regardless of explicit "inline" declarations
-- Brane
Received on 2010-12-15 10:30:57 CET