Menu
Looking at the define of NS_INLINE it seems that the advantage of using it over static inline is compiler compatibility, is that correct? Should NS_INLINE always be used instead of static inline on c functions in objective-c projects?
#if !defined(NS_INLINE)
#if defined(__GNUC__)
#define NS_INLINE static __inline__ __attribute__((always_inline))
#elif defined(__MWERKS__) || defined(__cplusplus)
#define NS_INLINE static inline
#elif defined(_MSC_VER)
#define NS_INLINE static __inline
#elif TARGET_OS_WIN32
#define NS_INLINE static __inline__
#endif
#endif
213
The main reason is performance: when used appropriately, inline functions could enable the compiler to generate more efficient code. A good strategy for identifying performance bottlenecks is to profile the code. Once that's done, the most effective way to improve performance is by focusing on the bottlenecks.
Only static inline definitions can reference identifiers with internal linkage without restrictions; those will be different objects in each translation unit. In C++, both const and non- const static locals are allowed and they refer to the same object in all translation units.
Static inline functions are simple. Either a function defined with the inline function specifier is inlined at a reference, or a call is made to the actual function. The compiler can choose which to do at each reference. The compiler decides if it is profitable to inline at -xO3 and above.
A static inline function is, in practice, likely (but not certain) to be inlined by some good optimizing compiler (e.g. by GCC when it is given -O2 ) at most of its call sites. It is defined in a header file, because it then could be inlined at most call sites (perhaps all of them).
Looking at the define of NS_INLINE it seems that the advantage of using it over static inline is compiler compatibility, is that correct?
Only in part. You must assess the dominant toolchain here, and ask "why was static inline not used, or why was it inadequate?". The dominant toolchain contains the attribute __attribute__((always_inline)). So there are really two parts to this:
a) Compatibility So it adds compatibility for multiple compilers.
b) Use of __attribute__((always_inline)) in the dominant toolchain. inline has devolved to be a simple request to inline. With always_inline, the compiler can still reserve the right to not inline the function (for obvious reasons). However, it also says "trust me, I want this inlined -- compiler, inline this if possible". This attribute restores some of the ability to inline to the programmer. This can be used for performance, but I suspect (in this case) that it has more to do with reduction of the number of private exported functions, rather than performance requirements.
Should NS_INLINE always be used instead of static inline in objective-c projects?
No. __attribute__((always_inline)) should be reserved for people who have had a lot of experience optimizing programs, and with use of this facility. This attribute can be applied to C functions, C++ methods, and other static calls. It cannot be applied to ObjC class or instance methods (which are dynamic). I mention that because the compiler, optimizer, and LTO are very good at what they do. Meanwhile, improper use of inlining can have (any of) several performance penalties. The exception (for people who have not spent significant time optimizing) is of course when one takes the time to measure the differences it makes.
80
Yes, it's for compiler compatibility, but I think it's more for the use of the frameworks than for your own code. You're free to use it, of course, but I wouldn't bother.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
