Parens to avoid CPP macros in foreign imports

Simon Marlow simonmar at microsoft.com
Wed Apr 7 14:58:59 EDT 2004


 
> Ian Lynagh wrote:
> > [...] I don't know if the performance hit is worth worrying about.
> 
> A definitive "No!" from my side here. Worrying about the cost 
> of function
> calls compared to inline code was probably a valid concern 3 
> decades ago,
> but with current L1/L2 caches far exceeding the main memory 
> of mainframes
> of that time we should probably simply ignore this "cost". Under some
> circumstances outlining some code into subroutines can even 
> speed up things
> on current machines due to better cache behaviour.
> 
> In a nutshell: If performance was the only concern, we should 
> include your
> patch (but I leave this to SimonCodeGenM), and you should 
> issue a bug report to the curses people.

Tough call, but I'm going to recommend leaving things as they are and
working around the curses problem.  Working around it is pretty easy:
invoke the offending macro via a stub C function.  Or compile your code
with the native code generator (-fasm).

We use macros pretty extensively in GHC's IO libraries.  Whether it
actually helps or not I'm not sure, but I don't want to have to measure
the difference that disabling them would make.

Cheers,
	Simon


More information about the Cvs-ghc mailing list