Open Phantom139 opened 7 years ago
The Tribes engine isn't that bad where significantly reducing your function count will impact performance. Most of the 'entry points' (various responders to events) called in Torque are called actually very occasionally considering the amount of CPU time the T2 engine spends executing itself overall. Only exception here is if you run a lot of self-scheduling loops but those can't be executed with any more granularity than 32ms at which point you will hit slow execution times if you generally try to do too much in that window.
I'd be more concerned with optimizing the control flow if you're worried about the performance of self-scheduled functions. Stuff like algorithmic optimization of the functions you are calling or changing the rate at which things are being called (there isn't a whole lot of things that will actually need the 32ms resolution and the more you scatter your schedules, the better overall performance you'll see....)
All this will really accomplish is making function management a bit harder in that you obscure function parameters behind generalized parameters (%arg1 ... %argn) as well as returns and the mere existence of said functions from searches based on normal function declarations. Not to mention it will get incredibly messy eventually, even if you split "function handlers" across multiple declarations (which might actually make it worse, ultimately). Eg. Which function handler provided so-and-so functionality OR the mere fact you have a ton of functions condensed into one.
Basically, all I can see being an issue is that there is some global function count limit (of which I'm not aware of, it probably just utilizes dictionaries there at which point it should support up to the number of functions you can create and fit in 32bit addressible space).
@Ragora I believe that the original TGE (Pre Release) that Tribes was built on did have a rough function limit somewhere that once you crossed would lead to the internal array definition going out of bounds, you could easily see this occuring when hardcoded functions would start to appear as not-found, and your game would crash shortly thereafter due to an access violation. I haven't noticed this issue in either TGEA or T3D, so I would assume as you have stated that the count was increased to 32bit.
Obviously the flow of the functions does become a bit more complex internally, however my prior tests with this have shown to not be an issue, and to be honest if anything, this gives me a much needed opportunity to "clean up" the old messy codebases.
There was a point in one of the prior versions of the mod (3.7 I believe) in which the internal count did come extremely close to the limit such that trying to run any form of external scripts would trigger the function count limit, this is why I replaced the chat command syntax that had almost been entirely standard in construction mods beforehand to the switch$ model that all of my mods now employ. Doing this has nothing to do with performance, more so just reducing the global function count such that the mod doesn't fall into the 3.7 problem again.
The response was just an all encompassing thought process as I didn't have motivations for this. Indeed I meant the count was ~32bits but on tribes as I was not aware of a function limit - I've seen many mods with quite a few declarations on file that had no issue.
What I said still applies. I'd worry more about the call paths instead of squishing things in this manner because it's counter productive to readability. Rather I'd worry about eliminating needlessly split off functions by inlining where possible. If you're sitting at this Max limit then I'd worry more about structural arrangement.
As prior work for the Shade Lord boss revealed, we can recover a huge amount of functions from TWM2 by simply compiling existing functions into "library style" functions that employ the following code style:
function TWM2Lib_x(%functionName, %arg1, %arg2, %arg3, %argN) { switch$(%functionName) { case "Blah": //Code Here } }
Multiple tests using this methodology show no losses to performance are taken when employing this method on calls that are rapidly handled (I.E: Bosses), and since a large amount of the mod backend are one-and-done style functions, we can recover a huge number of them by employing this method. This will be tested on one of the central parts of the mod, MainControl.cs to see if this is a viable replacement for most of the codebase.