Hi all, just dropped by and I'm happy to see nothing has really changed…
Although I'm well aware that most people in this thread is likely not really interested in facts I couldn't resist making a comment on this one.
First of all - of course the guys at beth HAS compiled the PC version with the appropriate flags for a release build! How can I know? Well, look at the overall loading speed and performance - anyone who has tried running a debug build of a game will know such performance is not possible without having inlining (and other optimization flags) enabled.
Secondly the modder made it easy for us - he provided the source code for his mod! Although I'm sure all you guys bitching about how this is "junior stuff", "just a matter of enabling O2" etc. has already read through the code (otherwise it would be kind of silly to make comments on other peoples work, wouldn't you agree?) let me explain a few things about it.
You'll see that the mod consists of 3 files: a patch program, a file with a list of code locations to patch up (function call sites) and a file with replacement functions. Most of the replacement functions are "manually inlined" versions of "getter/setter" functions.
A "getter function" is a very small function that simply returns a value. For example, a monster might have a function called "getHP" and that usually would just return a single value, stored in a "member" of the monster "object".
With "inlining" enabled the compiler MIGHT choose to replace a function call in the code with the content of the function being called. This is useful for small functions, because there is a certain CPU overhead involved in calling a function.
There are a number of cases where the compiler CANNOT inline a function though. For example:
- The function code is placed in a .cpp file instead of a .h file (mistake by programmer)
- The function is in another .dll
- The function is a "virtual" function (too technical to explain here)
There are many valid reasons why even a getter function might fall into one of the three categories above - WITHOUT implying that the programmers are amateurs!
Now, back to the mod. You'll see, in the file "code.inc" that one of the code stubs he inserts is "Patches.inline.getter_this_offset_4". This function simply returns the data placed 4 bytes from the start of an object.
To give an example, this might be inserted instead of a call to "getHP" - BUT it then assumes that the value is always found exactly 4 bytes from the start of an object. This is only true as long as the code isn't changed, for example patched by Bethesda. It also assumes, in the case of virtual functions, that this is the case for all implementations.
Such patches CANNOT be done by the compiler, and CANNOT be achieved by simply enabling the O2 compile switch.
Don't get me wrong, it's actually quite impressive (and hacky
) work of the modder - but personally I would only run with his patch if I had severe performance problems! A tiny mistake from his side might not result in a crash, but lead to unforseen and obscure bugs much later in the game.
This is also not to say the guys at Beth is entirely without blame. A performance profile might have indicated that the functions in question were hotspots, and a highlevel optimization in the code probably could avoid calling the functions so often.
But again, claiming that they just left out the O2 switch (on purpose even) - that's just plain silly!
Happy new year to you all!
