Let’s continue the series today by starting to look at structs. These are far more powerful in C++ than in C#, so today we’ll start with basics like defining and initializing them. Read on to get started!
Posts Tagged field
C# makes it easy to create large graphs of objects connected by their fields. The larger this graph grows, the more complex it is to deal with objects in the graph. It’s hard to look at code or set a breakpoint in a debugger and get an intuitive sense of all these connections. So today we’ll write a small tool to visualize an object graph!
C# APIs are chock-full of generics. Generic types, generic method parameters, generic return types, generic fields, generic properties, deriving from generic types, and generic constructors. We can find all of these in the Unity and .NET APIs. Some are more frequent than others, but we’re going to need support for all of them to make C++ scripting a viable alternative to C#. Today’s article continues the series by adding just that: support for all of these kinds of generics. Let’s dive into how to use them as well as some bonus items added to the project this week.
Reflection allows you to introspect your code at runtime. You can do very dynamic things like call functions by their name as a string. As such, it’s a really powerful tool when you code needs to be more flexible. Unfortunately, it’s slow. Really slow. Today’s article puts it up against regular, non-reflection code to show the difference in speed. It’ll also walk you through reflection in C# in case you’ve never used it before. Read on to learn more about reflection in Unity!
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!
This article is for the AS3 developer who’s decided to switch to Unity and doesn’t know the first thing about programming in C#. It’ll walk you through the basics of C# to get you oriented and productive.
The hidden describeTypeJSON function is faster than the XML-based describeType function by default, but we can make it even faster. Today’s article describe just how this is done and achieves a nearly 10x speedup!
Tip #8 in my Top 10 Performance Tips For 2012 was to reduce static accesses of variables, functions, etc. in favor of non-static variables and, especially, local variables. I neglected to reference one of my articles and it was pointed out to me that I hadn’t actually written such an article! So today I’ll elaborate on my tip and show why you should prefer non-static and local variables so you can find out just why it deserves its place as a top tip.
One of the very nice features of AS3 (and AS2 and JavaScript for that matter) is that you can dynamically access the fields of any object. This leads to much more dynamic code since you no longer need to know what field to access at compile time. As we’ve often seen with other dynamic features, this can come at a steep cost in terms of performance. Today we’ll see just how slow accessing fields this way is to get a good idea of just how much performance we give up when using this feature.
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.