Aside from "tricks" to use, is it not possible to program the game for 64-bit versions and use the increased RAM available to avoid having to cull history? I'm guessing it's not an easy thing to program though, unfortunately.
It's times like this that I wished I knew how to program.
"Just throw more RAM at the problem" doesn't really help anything but the crashes from going over 2 gigs of RAM.
Besides, if you have geometric complexity growth, then doubling your RAM only lets you go one iteration further, anyway.
What you need to do is change the slope of the complexity curve.
You need to create more JPG-like (or better yet, PNG-like) means of handling information in general - this game tracks far too many items that are simple duplicates of each other that clutter up the gameworld.
If you have a warehouse full of limestone stones, then every single iteration of the game clock will have the game check each and every one of those stones for if their status has changed (such as if temperature has increased)... but you can look at that and tell immediately that the status of that warehouse has not changed in a long, long time, and there are no reactions for that limestone to undergo... but the game checks each and every individual item for a reaction every single game tick, anyway.
Wouldn't it be faster to just check that area for some sort of condition change, and then assume that if the items in that area hadn't been changing for the past some-odd frames, that you don't need to bother checking the individual items, and skip over the whole check?
This sort of thing gets done with water already, at least, although it's somewhat buggy - water that fills up an area 7/7 and doesn't move will be considered "settled", and the game doesn't even check for movement on those tiles of water, except to occasionally check to see if someone has breached a wall holding that water back.