Today we continue the series by looking at a pair of powerful, related features in C# 7.3: ref return values and local variables. These enable some great optimizations, so let’s look at the IL2CPP output for them to make sure it’s as good as it looks.
Posts Tagged local
C# has properties similar to AS3’s get and set functions. These functions can even be auto-generated for you, which is very convenient. However, the auto-generated versions don’t expose the so-called “backing field” that the property gets and sets. This brings up a question: is there a performance penalty to using an auto-generated property rather than manually implementing the property so we can directly access the backing field? The get and set blocks are like functions, so are we paying function call overhead for them every time we access our own private pseudo-variables? Finally, could we do even better by skipping fields altogether and working on local variables instead? Today’s article puts all three approaches to the test by analyzing the bytecode that’s generated and the performance within a Unity test environment. Read on to see which way is fastest!
Recently, I’ve seen a lot of performance-critical code that has made heavy use of field variables. For example, an expensive loop might look like this: for (var i:int = 0; i < this.numObjects; ++i). I've recommended to some of the programmers writing such code that they modify it to cache the field variable as a local variable to improve performance. Was I right to recommend this? In today's article I'll examine the read and write times to see if caching field variables locally really improves performance.
I am often burned by MXMLC: the AS3 compiler. When I am, I find this infuriating and look for the reason why this happened. Today I’ll tip you off about this problem and delve into what it means if you happen to trigger it.