Inline P_MobjWasRemoved

Originally @Lugent's patch, only submitting it myself because of his lazy ass and the impact seemed quite large. Though, I'm not surprised considering how often we call it in combination with how costly branching with a subroutines are.

NOTE: I haven't tested it, I'm trusting @Lugent on him doing the testing and benchmarks.

I did a quick test and saw no noticeable difference in testing, but considering how small the function is, there really is no reason to not inline it. It's possible that it's also hardware-specific and that my hardware doesn't have a big impact on this.

I'll see if there is any way forward on this issue - currently I'm contemplating on just making thinker functions per type so we can get rid of extra overhead caused by a monolith like this, but that's going to be a lot of work to implement.

If you going to inline a function, use the macros FUNCNOINLINE and ATTRINLINE so both GCC and MSVC will be FORCED to inline the function.

If it failed to inline, it would've warned me already (then again, this is with GCC, not MSVC): https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Winline

Also, we should seriously turn this warning off when compiling with DEBUGMODE=1, since it floods the compilation unit with so many bogus warnings that you can't see legitimate issues.

I'll adjust anyway for MSVC's sake, but this should work as intended with GCC.

The issue that diff versions of GCC (and MSVC) have will warn on saying it will not inline the function, so we have macros to force it, so it will be the same, no matter what version of compilers we are using...

I don't disagree, but worth pointing out: SRB2 has many more occurrences of static inline than of FUNCINLINE static ATTRINLINE, so it makes sense that one might accidentally choose the former when looking at the codebase.

(There are even a few cases where they're mixed like FUNCINLINE static inline (in m_fixed.c).)

added 1 commit

• 3470b930 - Use inline attributes

Compare with previous version

Without:

With:

does seem to have an impact

Interesting, since for me, the difference were within margin of error on CEZ2. This might be hardware-specific, then (speculating: maybe some CPUs are less impacted by subroutine branches than others)?

mentioned in merge request !2616 (merged)

Closing in favor of !2616 (merged)

closed