[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual

From: James Youngman
Subject: Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual pointer semantics
Date: Tue, 10 May 2005 00:33:14 +0100
User-agent: Mutt/1.3.28i

On Mon, May 09, 2005 at 10:04:34PM +0200, Bruno Haible wrote:
Bruno> Paul Eggert wrote:
Paul> I installed this patch into coreutils.
Paul> +static int
Paul> +fts_compar (void const *a, void const *b)
Paul> +{
Paul>    /* ... */
Paul> +  return pa[0]->fts_fts->fts_compar (pa, pb);
Paul> +}

Bruno> The cost of an extra function call per comparison is pretty high, just
Bruno> to get rid of a cast that will most likely never lead to any damage.
Bruno> Therefore I would conditionalize this extra function indirection with
Bruno> or similar, so that it is disabled by default.

It's a very short static function, surely the overhead is going to be
very small and compilers are likely to be able to inline the actual
subroutine call away in any case.  For cases where fts() is searching
only a small number of files/directories, the cumulative overhead of
this static function is likely to be almost unmeasurable, and on
larger directory hierarchies I'd assume that the overhead of calling a
static function is small compared to the amount of disk I/O required
to search the large directory tree.  

I agree that there is an overhead in there but I can't agree that it's
worth paying the maintenance/complexity cost of having conditionalized


reply via email to

[Prev in Thread] Current Thread [Next in Thread]