Thankfully, Flex Builder has a profiler tool built-in, and leaving my application running for hours in the profiler revealed the rapid accumulation of instances of a mystery class TextAccImpl, which it’s package structure revealed was part of the new Text Layout Framework.

This was more problematic than you may imagine, as not only is the TLF still in beta, but was an integral part of my application as it gave us the ability to switch seamlessly between English and Arabic.

After spending time tweaking my code to check if I was using the API incorrectly, it became apparent it was a bug in TLF itself. Googling didn’t find anything, so I resorted to the official TLF blog, where I noticed a post announcing they were releasing weekly builds to their Adobe Labs download page.

As I was compiling against the version of TLF that came with the Flex 4 MAX Preview, I decided to upgrade by adding the latest weekly build (411 at that time) as an external library to my project. After making the necessary changes to my code to reflect the API changes they’d made, I left my application running in the profiler overnight and to my relief the bug had been fixed.

If anyone is experiencing dramatic degradation of performance over time after adding the TLF to your application, I’d recommend you upgrade to the latest weekly build.

There’s no information on the 10.5.3 support page about the fix, but from a quick read of some related WebKit bug reports (18972 and 19144) it seems likely an unreported patch to CFNetwork has done the trick.

Discovered this by chance this morning when checking over a site we’re launching soon and noticed the files were loading too fast not to be cached!