You are building up the entire output array and then joining it. I was suggesting doing that incrementally. Like this (untested):\r\n

\r\n   var myImageString = [];\r\n   for (var i = 0; i < myImageArray.length; i++) {\r\n      var myImageThisRow = [];\r\n      for (var j = 0; j < myImageArray[i].length; j++) {\r\n         myImageThisRow.push(HexMap[myImageArray[i][j]]);\r\n      }\r\n      // Reduce the number of objects to be nice on gc\r\n      myImageString.push(myImageThisRow.toString());\r\n   }\r\n

\r\nPast experience with large JavaScript datastructures tells me that while you'll thrash a lot less than when you create tons of garbage, the garbage collector still thrashes on lots of small objects that aren't to be collected. (It keeps on figuring out what it can collect..and finds nothing.) The above strategy keeps the number of objects that it wants to handle under control.

\r\n\r\nAs for not building it in memory, I wish that I knew how to do that, but I don't. I only know how to speed things up slightly.

\r\n\r\nCheers,
\r\nBen

I just did that to reduce bookkeeping in the code.

The problem is that as you use lots of memory, you trigger frequent garbage collection runs. If there are lots of small objects, those runs take a long time. So you are spending a lot of CPU looking for garbage that isn't there.

Switching from having a very large number of small objects to just having a bunch of large objects and another bunch more small ones doesn't materially effect how often it runs garbage collection, but it does make a garbage collection (at least with some allocators) run much faster because it has fewer objects to look at until it decides that there is no garbage to eliminate.

It isn't an obvious thing to do to tune performance, unless you've faced the same problem before. (Which I have.)

Cheers,
Ben