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 > me.
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. Thanks, both. -- 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
