Which JSON library creates the most garbage? That’s a common question I get in response to my JSON articles. Today’s article finds out the answer!
I wrote an article when Unity 5.3 came out to test its built-in JSON serializer library against some of the open source JSON libraries. Today’s article updates with Unity 5.4 and adds a requested JSON library—Full Serializer—to the mix. Has Unity 5.4 improved performance? Is the new version of JSON.NET any faster? Can Full Serializer best them all? Read on to find out!
Every time I see
for (var i = 0; i < array.Length; ++i) I wonder if accessing that
Length property is slow. Should I cache it? It’s comforting to know that
for (int i = 0, len = array.Length; i < len; ++i) is only dealing with local variables except on the first loop. Local variables must be faster, right? Likewise, I wonder the same thing about
List<T>.Count. I finally got around to running a test to see if caching these length properties makes any performance difference. The answers might surprise you!
File I/O can be a major performance bottleneck for many apps. It’s all too easy to read files in a way that is massively inefficient. Classes like
BinaryReader make it really easy to write super slow code. Today’s article explores why this happens and what can be done about it. Read on to learn more!
One of the biggest source of bugs in our apps is state: all of that persistent data we keep around in memory. When things change we need to make sure to update all of it at the right times and with the right new parts of the state that changed. Inevitably things get out of sync and our app is in “a bad state”. Today’s article discusses some ways we can prune the “graph” of objects that we create in OOP so that there’s less state to maintain. Read on for some interesting techniques that could help you prevent bugs!
Callbacks are a mainstay of the real-time games and apps we build in Unity. We’re constantly writing asynchronous code for every operation from walking a character to a destination to making a web call. It’s really convenient for these functions to “call back” and report their status so we know how the operation is going. Unfortunately there are also a lot of dangers that come along with this. Today we’ll look into the surprisingly large number of ways you can “call back” in C# and some of the ways you can get burned doing so.
A lot of times we want to take some action when a value changes. If the player’s level increases I want to play a “ding” sound effect. If a player loses health points I want the screen to flash red. Today we introduce
Observable<T>: an easy way to track these value changes. Read on for the source code and examples!
Taking another break from the iterator series, this week we’ll take a look at an exciting .NET feature that can easily and cleanly remove the calls to a function throughout the whole code base. Unity uses this for
Debug.Assert and you can use it for all sorts of functions, too. Wouldn’t it be nice if we could strip out all the debug functions from the production build of our game but leave them in during development? Read on to learn how!
We’re nearing the end of the series to build a no-garbage replacement for
System.Linq. Today we tackle functions that work on already-sorted ranges and functions that work on ranges that are in heap order. These include common set operations like “union” and “intersection”. Read on to see how to use them and for the updated library that you can use to eliminate your garbage creation!