Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve Console Function Calls #81
This branch makes the following changes to the Console/TorqueScript system:
In essence, this improves the performance of TorqueScript so that calling functions is no longer expensive in the case of passing numbers around. It also optimizes variable assignment, so when assigning numeric variables it will no longer perform an unneccesary string conversion.
Relevant benchmarking figures are available here:
The actual benchmarking code I used is here: https://gist.github.com/3760645
While I have a few more ideas to improve the scripting engine (e.g. improving field access), I feel that changing the way script functions are binded to the engine is both significant and useful enough to make a pull request now.
This code has been tested on Windows and Linux. It has also been tested in the case of Singleplayer and Multiplayer. Unfortunately while I have tested this as much as I can, there could still be edge cases where this breaks something so I encourage anyone interested in incorporating these changes to test them against their script code.
@DavidWyand-GG In terms of the function calls, consolefuncrefactor is the one you want. This deals with function calls, and is fairly stable (AFAIK).
The other branch in my repository (consoletyperefactor) deals with changing the type system. Unfortunately there are a few killer bugs in the editors in that branch, so it isn't suitable for inclusion at this time.
These changes have been placed into a consolefuncrefactor branch on the main repo and the community has been asked to help test. We'll let the testing happen over the next couple of weeks, and then integrate these changes with the development branch if all goes well.
referenced this pull request
Jan 14, 2013
I have been using this while developing tasman and have come across one difference to stock T3D so far involving comparisons with floating-point numbers. However this is already completely dodgy in scripts anyway. For example:
So on one hand I wouldn't worry too much about it. On the other, if someone is relying on the current badly-defined behavior, they may get a surprise.
I discovered this some time ago and managed to reproduce it in the console, but I've forgotten the sequence that demonstrated it. At the moment, all I can say is this tasman test fails in the refactored branch, but not in stock:
With the error:
The reason I can't demonstrate this simply is because tasman internally shifts values around quite a bit to give a nice interface. So diagnosing the exact problem may take me some time.
Don't ask my why I tested that! I was just messing around. But it seems to have found something after all...
If I recall correctly in this branch type of variables will be maintained when you pass them through functions rather than being converted to strings.
It could be that the float is being converted to a string which will print out the number in the same precision for both values, despite the comparison normally failing. Floating point numbers can be very strange!