AS3 has never had very good support for multi-line strings… until now. Today’s article discusses the proper and improper ways of writing multi-line strings and delves into the bytecode so you really understand what’s going on.
Posts Tagged string
Dealing with XML files can very easily trigger Flash to “leak” memory. Your app may only keep a tiny fraction of the XML file’s contents, but the whole file may stay in memory and never get garbage collected. Today’s article examines how this happens and how you can clean up all that unused memory.
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.
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 Context3D.drawTriangles or 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: joinN and joinNLabeled. These functions are like Array.join and 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 [reap], [mark], or [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: int, uint, Number, Boolean, String, and even XML.
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.