Adobe’s as3corelib has a JSON parser. It’s quite stable, and widely used. It’s also dirt slow, and has a hard time getting through large amounts of data. Other libraries are either slower, or prohibitively licensed.

So, I set out to write the best AS3 JSON library I possibly could. I’m calling it actionjson.

encodeJson and decodeJson

Using pretty much every trick I could think of, I wrote a new blocking JSON encoder and decoder, much like the as3corelib version, but only capable of processing much faster. They’re also single, isolated functions, keeping them light and unbound from any extra dependencies.

On large objects the blocking decoder performs up to 5-6x faster. The JSON encoder has more modest improvements, since the as3corelib version is already reasonably optimized, but it’s still significantly faster at handling strings and objects. It’s 2-3x faster at them them in my tests.

ason was another JSON library that looked promising (if not for its license) that I wanted to compare actionjson against, but in my tests it seemed to have some severe performance problems. The decoder was around 10-20x slower than as3corelib’s decoder. The encoder was much better, even performing better than encodeJson in a few tests, but still performing 2-3x worse on objects, arrays, and long strings.


I also wrote an asynchronous JSON decoder that can parse data incrementally, either as the data comes in, or in specified chunks. It has it’s own stack, which adds a lot of overhead, but still ends up around 2x faster than the one in as3corelib.

There is no asynchronous JSON encoder included, mostly because I don’t think it’s paticularly needed at this point, but I think it would be a good addition to the library in the future.

Wasted cycles

The advantages largely come from avoiding overhead from classes, constants (yes, constants), switch and if statements, and by analyzing using ByteArrays instead of Strings.

I actually tried using Apparat in my project, specifically tdsi so i could use Flash’s direct memory access opcodes. Unfortunately it performed at about half the speed, although I’m not sure why.


actionjson is available on github here. It’s licensed under the Apache License 2.0, so it’s usable in proprietary and open-source projects. The library includes the (simple) unit tests I used to verify my code, as well as the speed tests.

Feedback and contributions are very welcome. Leave comments here, email me, or fork me on github.

The Flash 10 standalone debug player used to dump trace messages to standard output like any good program, and for a time, it was good. Somewhere along the line it seems to have stopped doing this and it’s annoying me. Here’s an (obvious) trick to produce the same result (on Linux, more on OS X below). Run tail -F in the background on flashlog.txt:

$ tail -F ~/.macromedia/Flash_Player/Logs/flashlog.txt &
$ <build command> && flashplayer something.swf

After running that first command once, it’s back to normal. I can Ctrl+C to kill the player (the close button is so far away..) and I get nice formatted debug output.

You’ll have to get mm.cfg set up to get Flash to dump to that file. Read up on it, or if you’re feeling tl;dr, just run this command:

$ echo "ErrorReportingEnable=1nrTraceOutputFileEnable=1" > ~/mm.cfg

I haven’t tried this on OS X, but it should probably work the same, just change the path to flashlog.txt:

$ tail -F ~/Library/Preferences/Macromedia/Flash Player/Logs/flashlog.txt &

Finally, if you’r not familiar with background jobs and want to be rid of trace output, run “fg” to take control of the tail process and then Ctrl+C to kill it.