Get DFhack and use the commands
"clean map"
"clean units"
"clean items"
...
Right, but the idea is that if, even when deleted, those splatters and objects you atom-smashed still "took up" a slot in an array in an index vector ...
IIRC there was some strong indications in previous versions that the memory hacks used by DFhack, etc. had some serious hidden limitations in that they effectively sidestepped various optimization and/or garbage collection (in the computer sense) triggers. It was well documented that hacking the removal of magma from a tile did *not* trigger whatever internal routines fix up temperature propagation / cleanup; and that a tile that had magama hack-removed could still burn many seasons later. As I understand it Toady's code seems to have some fairly significant "lazy update" processing to improve performance, and using hacks can trigger weird side effects connected to not running cleanup routines.
A useful experiment to run might be to take an existing prosperous fort with really good trade and clone off a copy. The fort should have plenty of available haulers, several (preferably plenty of) experienced miners and plenty of picks, an atom-smashing setup ready to go but not used yet, several stonecrafting and masonry workshops with at least competent dwarves to man them, something to make reasonable bins out of (preferably ordinary wood in quantity), and be expecting a large wagon equipped dwarf caravan in the next few months.
Fire up the copy, record averaged FPS, and then dig out a huge amount of stone with good miners, initially just having it lie there. Record averaged FPS (hopefully significantly lower, if not keep digging), then save the fort and make several parallel copies.
On the same system as used so far, handle all the stone differently, and record how averaged FPS changes. Because there may be some deliberate cleanup involved in the save / load process, it's important to run the experiment from here out with the cases in a single session, record averaged FPS, then save, exit DF, and load and record averaged FPS again.
* Control: Stone just lies where it fell from mining, before & after save/exit/load
* Hide: Stone is left as above, but hidden from view using DF's internal option, before & after save/exit/load
* Stockpile: Stone is carried by dwarves into large stone stockpiles, before & after save/exit/load
* Block: Stone is processed by masons into blocks, and stored by dwarves in bins in stockpiles, before & after save/exit/load
* Mug: Stone is processed by crafters into mugs, and stored by dwarves in bins in stockpiles, before & after save/exit/load
* Atom-smash: Stone is carried by dwarves to the atom-smasher, and smashed out of immediately obvious dwarf reality, before & after save/exit/load
* Pre-trade: Stone is set up to be traded away (probably pre-staged in stockpiles near the trading post), before & after save/exit/load
* Hack Direct: Stone is removed directly with hack tools, before & after save/exit/load
* Hack Temp: Stone is changed to something which boils away at room temperature, preferably with a minimum of Fun, before & after save/exit/load
Then once the traders arrive, run some additional copy cases:
* Trade away as much raw stone as you can, let traders leave map, before & after save/exit/load
* Trade away same number of blocks, let traders leave map, before & after save/exit/load
* Trade away same number of mugs, let traders leave map, before & after save/exit/load
There's no way I'm going to have time to run cases like this in the next few weeks, but the above set should tell us a lot about not only how DF handles storage "normally", but how it interacts with the hack tool's and some exploits fiddling around with the guts of data structures without calling methods properly. Ideally, you'd take another set of measurements after a season change; there's some possible evidence that there is data cleanup run on the season change already.