Jeff King <p...@peff.net> writes:
> I think there are basically three classes of solution:
> 1. Declare __NO_INLINE__ everywhere. I'd worry this might affect other
> environments, who would then not inline and lose performance (but
> since it's a non-standard macro, we don't really know what it will
> do in other places; possibly nothing).
> 2. Declare __NO_INLINE__ on mingw. Similar to above, but we know it
> only affects mingw, and we know the meaning of NO_INLINE there.
> 3. Try to impact only the uses as a function pointer (e.g., by using
> a wrapper function as suggested in the thread).
> Your patch does (1), I believe. Junio's patch does (3), but is a
> maintenance burden in that any new callsites will need to remember to do
> the same trick.
> But your argument (and reading the mingw header, I agree) is that there
> is no performance difference at all between (2) and (3). And (2) does
> not have the maintenance burden. So it does seem like the right path to
Agreed. If that #define __NO_INLINE__ does not appear in the common
part of our header files like git-compat-util.h but is limited to
somewhere in compat/, that would be the perfect outcome.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html