In case you want a simple explanation for this story: he tried to run an old pre-iPhone mobile game on a computer. The game runs very slow on computers, which is surprising considering the performance difference between these old phones and a modern computer.
The reason turned out to be that the game runs a memory cleaning command to avoid bugs arising from lack of space. Since modern computers have 10000x more memory to clean up, these commands now take way more time to complete, and thus slow the whole game down.
> Since modern computers have 10000x more memory to clean up
The understated insane part of this is that emulating a 100mhz ARM CPU with 128kb of RAM apparently takes gigabytes of RAM to accomplish. What on earth is that emulator doing?
Given the details in the tweet, it might be simply translating GC run from emulated to host context. Not what you would ever want to do but it's abandonware from years ago after all, it might have been "slow but bearable" back when it was being developed.
It seems kind of crazy to me that people were using a GC language on a device with 128kB of memory. John even mentions how he was forced to run the GC on every frame to avoid problems. I would think when you are that constrained you would be closely tracking your memory usage. It's probably a miracle that those games weren't constantly hitching and crashing due to slamming up against the memory limits.
> It seems kind of crazy to me that people were using a GC language on a device with 128kB of memory.
Look up JavaCard which apparently is a thing that still exists. It uses the Java language without a GC - that programming environment is truly miserable to work with.
Best practice was to pre-allocate everything, or at least not allocate insane amounts of objects per-frame if at all possible such that System.gc() would become a no-op up to tracing and maybe defragmentation anyway.
> Since modern computers have 10000x more memory to clean up,
The thing I don't understand is that the application presumably isn't using any more or less memory than it did when it ran on a 1/10,000x computer. You're not scanning the whole RAM for memory to clean up, just the allocated memory. And on a game that was designed to use 128kB, that's presumably not very much.
If the game was built with premature scalability and you're letting it see how much RAM there actually is, instead of giving it 128KB, I can see it hitting some bugs and getting really aggressive.
The reason turned out to be that the game runs a memory cleaning command to avoid bugs arising from lack of space. Since modern computers have 10000x more memory to clean up, these commands now take way more time to complete, and thus slow the whole game down.