String.charCodeAt is a simple function so you might expect the function call overhead (huge in AS3) to making calling it frequently quite slow. You’d think that there’s no way an
charCodeAt-using AS3 function could beat a built-in
String function like
indexOf. Would you be right? Today’s article examines this special function to see if we might defy conventional wisdom and achieve a performance boost.
Posts Tagged string
Strings and integers sort differently. Unfortunately, this became a problem for me during some recent experiments with Starling. It could be a problem for you too in a variety of situations. Today we’ll look at a workaround I’ve developed to solve this problem, which isn’t nearly as straightforward as you might think.
This week’s article offers another useful utility function:
indexedTrisToString. This function is especially useful when dealing with 3D engines such as those based on
Graphics.drawTriangles. It helps to untangle the complicated indices/vertices format that these API functions require into something much more readable and, therefore, debuggable.
It’s been a while since I’ve posted a utility function, but today I’m breaking the streak and posting a couple of related functions I frequently find useful in debugging:
joinNLabeled. These functions are like
Vector.join, but they group elements of the array to make the resulting string much easier to read.
When a recent comment asked about string concatenation performance, I realized that there are a lot of ways to build strings in AS3 and I hadn’t tested any of them. Leaving aside the sillier ones like the XML class or joining
Array objects, we have two serious contenders: the lowly
+ operator (i.e.
str + str) and the
ByteArray class. Which will triumph as the ultimate way to build strings quickly?
During some recent memory profiling I was reacquainted with just how many ways there are to unknowingly allocate an object in AS3. The problem is seldom the allocation itself, but rather the later garbage collection (GC) to delete those objects. Ever used a Flash profiler only to see a huge chunk of your CPU time going to
[sweep]? Yeah, that’s the GC at work. Today’s article talks about some of the ways you end up allocating objects in AS3 without using the
new keyword. These subtle errors can end up costing you!
Five months ago I said I’d talked about explicit type conversion. I hadn’t, really. What I talked about before was type casts. A cast changes the type, not the data. Today, I’m actually going to talk about type conversion and show you the costs of converting between all of your favorite types:
String, and even
It struck me recently that there are a lot of ways to convert variables of many types to a the String type. The ease of doing this is one of AS3′s strengths over languages where it’s error-prone, possibly insecure, and just plain difficult. The C language is the most obvious example of this and, since then, seemingly every language has enshrined string conversion in ways ranging from global String() functions (AS3) that take any variable to adding toString() to the base Object type (Java, AS3, others). AS3 seems to have chosen “all of the above” and there are now many ways to convert to a string. Below I’ll look at them from a performance standpoint and see if the everyday, run-of-the-mill boring string conversion can be improved by choosing one option over another.
I was reminded about the flash.sampler API by Grant Skinner’s recent post about it. While only available in the debug player, it can still tell us some valuable information about what goes on in the release player. Today I’m using the getSize function to find out how much memory overhead various classes impose, even when they are empty.