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