[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] diff-optimizations-bytes branch: avoiding function call overhead (?)

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 15 Dec 2010 11:29:39 +0100

On Wed, Dec 15, 2010 at 10:30 AM, Branko Čibej <brane_at_xbc.nu> wrote:
> 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

It was a Windows build (x86), with "Release" configuration, compiled
with Visual Studio Express 2008 (when measuring performance of this
branch, I always use a Release build, a Debug build is at least twice
as slow; I only change to a Debug build if I'm having problems,
needing to debug etc.).

I have not used any special compilation options, so maybe that could
also make a difference (but, to be honest, I'm lacking the expert
knowledge about C compilers, options, platform specific things etc.
for this).

Maybe the function is a little bit too large/complex for the compiler
to automatically inline it without any hints? Or maybe writing it
differently, like Stefan suggests, could help the compiler to inline
it without needing explicit inline declarations... I'll experiment a
little bit (in a couple of days, having a huge shortage of time now

Received on 2010-12-15 11:30:36 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.