We got a report of a bug with the new 3D model viewing extension on Wikimedia Commons, where a particular file wasn’t rendering a thumbnail due to an out-of-memory condition. The file was kind-of big (73 MiB) but not super huge, and should have been well within the memory limits of the renderer process.
On investigation, it turned out to be a problem with how three.js’s STLLoader class was parsing the ASCII variant of the file format:
- First, the file is loaded as a binary ArrayBuffer
- Then, the buffer is checked to see whether it contains binary or text-format data
- If it’s text, the entire buffer is converted to a string for further processing
That conversion step had code that looked roughly like this:
var str = '';
for (var i = 0; i < arr.length; i++) {
str += String.fromCharCode(arr[i]);
}
return str;
Pretty straightforward code, right? Appends one character to the string until the input binary array is out, then returns it.
Well, JavaScript strings are actually immutable — the “+=” operator is just shorthand for “str = str + …”. This means that on every step through the new loop, we create two new strings: one for the character, and a second for the concatenation of the previous string with the new character.
The JavaScript virtual machine’s automatic garbage collection is supposed to magically de-allocate the intermediate strings once they’re no longer referenced (at some point after the next run through the loop) but for some reason this isn’t happening in Node.js. So when we run through this loop 70-some million times, we get a LOT of intermediate strings still in memory and eventually the VM just dies.
Remember this is before any of the 3d processing — we’re just copying bytes from a binary array to a string, and killing the VM with that. What!?
Newer versions of the STLLoader use a more efficient path through the browser’s TextDecoder API, which we can polyfill in node using Buffer, making it blazing fast and memory-efficient… this seems to fix the thumbnailing for this file in my local testing.
Just for fun though I thought, what would it take to get it working in Node or Chrome without the fancy native API helpers? Turns out you can significantly reduce the memory usage of this conversion just by switching the order of operations….
The original append code results in operations like: (((a + b) + c) + d) which increases the size of the left operand linearly as we go along.
If we instead do it like ((a + b) + (c + d)) we’ll increase _both_ sides more slowly, leading to much smaller intermediate strings clogging up the heap.
Something like this, with a sort of binary bisection thingy:
function do_clever(arr, start, end) {
if (start === end) {
return '';
} else if (start + 1 === end) {
return String.fromCharCode(arr[start]);
} else {
var mid = start + Math.floor((end - start) / 2);
return do_clever(arr, start, mid) +
do_clever(arr, mid, end);
}
}
return do_clever(arr, 0, arr.length);
Compared to the naive linear append, I’m able to run through the 73 MiB file in Node, and it’s a bit faster too.
But it turns out there’s not much reason to use that code — most browsers have native TextDecoder (even faster) and Node can fake it with another native API, and those that don’t are Edge and IE, which have a special optimization for appending to strings.
Yes that’s right, Edge 16 and IE 11 actually handle the linear append case significantly faster than the clever version! It’s still not _fast_, with a noticeable delay of a couple seconds on IE especially, but it works.
So once the thumbnail fix goes live, that file should work both in the Node thumbnailer service *and* in browsers with native TextDecoder *and* in Edge and IE 11. Yay!