Question

I’m writing a casino game in which I need to encrypt all the data I pass through sockets, so I want as much performance as I can get, because encryption and decryption may happen quite a lot, and I don’t want it to be laggy.

My question is which is faster performance-wise when you have a String and you want to get it’s characters at high speed, myString.charAt(i) or having var a:Array = myString.split(''); and then getting them like this a[i];

My for cycle may run 60-100 times or more. Thanks in advance

Answer 1

benbjo’s advice is a solid one. If performance is really a concern, the best test case is the situation where you’re actually going to use your code, not least because of garbage collection and the JIT’er making things unpredictable in terms of the actual performance.

That said, the charAt approach in general will be (20-50%) faster than split(). Memory-wise there shouldn’t be much of a difference – both approaches are creating a new string per character. In addition to that, the split() obviously also creates an additional array.

A comparison of these two methods:

charAt:

var s:String = "";
for (var j:int = 0; j < len; j++)
{
    // The string concat seems to be enough to confuse the JIT compiler.
    s += v.charAt(j);
}

split:

var s:String = "";
var arr:Array = v.split("");
for (var j:int = 0; j < len; j++)
{
    // The string concat seems to be enough to confuse the JIT compiler.
    // Using just arr[j] seems to be unfairly optimized.
    s += arr[j];
}

The relevant compiled ABC byte code is predictably identical between the two, except the call to split, and the array access vs. calling charAt(). In other words, no crazy optimization stunts by the ASC compiler (those are rare anyway).

10 runs, 1000 iterations each of the above code, release build on release player:

FP WIN 11,5,502,110           :  #Runs  #Iter           Avg           Min           Max          Iter
charAt :: string length: 50   :     10   1000        9.0 ms          6 ms         10 ms     0.0090 ms
split  :: string length: 50   :     10   1000       13.0 ms          8 ms         19 ms     0.0130 ms
charAt :: string length: 500  :     10   1000       68.5 ms         58 ms         97 ms     0.0685 ms
split  :: string length: 500  :     10   1000      100.5 ms         86 ms        136 ms     0.1005 ms
charAt :: string length: 1000 :     10   1000      149.3 ms        119 ms        202 ms     0.1493 ms
split  :: string length: 1000 :     10   1000      201.2 ms        162 ms        261 ms     0.2012 ms
charAt :: string length: 2000 :     10   1000      283.8 ms        230 ms        378 ms     0.2838 ms
split  :: string length: 2000 :     10   1000      326.9 ms        307 ms        423 ms     0.3269 ms
charAt :: string length: 4000 :     10   1000      575.8 ms        475 ms        752 ms     0.5758 ms
split  :: string length: 4000 :     10   1000      665.0 ms        609 ms        888 ms     0.6650 ms
charAt :: string length: 5000 :     10   1000      650.9 ms        581 ms        915 ms     0.6509 ms
split  :: string length: 5000 :     10   1000      863.4 ms        769 ms       1219 ms     0.8634 ms
charAt :: string length: 10000:     10   1000     1300.5 ms       1155 ms       1707 ms     1.3005 ms
split  :: string length: 10000:     10   1000     1797.3 ms       1534 ms       2461 ms     1.7973 ms

Avg = average time for each run (of 1000 iterations)

Min = minimum time for a single run

Max = maximum time for a single run

Iter = average time for a single iteration.

The variance between runs is fairly large, likely due to garbage collection happening during some of the runs. But the result is consistently in favour of charAt(). Making the split() call once before each run rather than redoing it in each iteration doesn’t make much difference. In other words, the difference in performance really does lie in accessing the array being slower than calling charAt(). It’s not the huge difference, however, that you’ll get from, say, using indexOf instead of a regex for searching a string.

In general, although it’s not a hard-and-fast rule, the most obvious approach to simple tasks like string manipulation will likely be the faster one. The FlashPlayer team spent a lot of time optimizing string manipulation, concatenation etc.