Secret BlitzMax optimization I found
BlitzMax Forums/BlitzMax Programming/Secret BlitzMax optimization I found
| ||
| I had wanted to make this post better and with code samples and the assembly output to show the optimization in action, but I've been very busy and won't have enough time for quite a while so I'm just going to put it out there and see what happens. BlitzMax methods are implemented in a similar way to C++ virtual functions, but if you never override the method in an extended type, you are wasting time on the virtual function overhead when a simple function would do. I've noticed that if you mark a type which doesn't extend from any other types, as Final, all its methods in the output assembly code will be coded as regular non-virtual functions! And you will not suffer the virtual overhead unnecessarily. I've not tested more specific examples. Eg if you mark a method as final which is introduced for the first time and so doesn't override an existing method, whether it comes out as virtual or not. And I have limited understanding of assembly so my observations could be wrong. The TLDR is if you have a simple type which you never extend, marking it as final will give a very tiny but non-zero speed improvement to calling its methods. Last edited 2011 |
| ||
| 1) I once did some speed tests on this (no longer have the code and it was a few years ago) and found that types marked final were slightly slower. 2) Virtual function overhead is in the order of a few microseconds per million calls http://stackoverflow.com/search?q=virtual+function+overhead |
| ||
| 1. Without the code for me to try, that statement is meaningless. 2. Never said it was a major difference. |
| ||
| On a similar (But again lost listing) note. All member functions of a type where faster if they returned a value, EVEN is that value was un-allocated to anything. It was a petty differance if I remember correctly, and made it harder to follow the code. This if true however is quite useful, but I think Id still be tempted to say that unless the speed is major I would rather keep the "Final" keyword for use when the function is, as they say, final |
| ||
| I've used it for things such as a TVec type which has just 2/3 numbers and a few methods to add it to other vectors and so on. I'm never going to extend that. I would like these claims of random things being faster to be backed up before being made. Why would it be slower not to return a value? It's an operation less. On strict mode, all functions and methods implicitly return an int of 0. How did you measure it, what settings?? |
   |