Should I cache to disk the memory used by my undo stack?
I've written a program what uses an undo stack to keep track of edits the user makes. At the moment it is using a lot of memory because some of the states it has to remember track objects of around 10k bytes or so and collectively they can chew up a lot of memory over the course of a single session. I was thinking that I could get around this by using a file to cache some of the weightier objects to disk, but then I was thinking that virtual memory ought to be doing that anyway.
Does it make sense for me to do my own caching to free up memory, or can I rely on the OS and existing memory managers to do that for me?
Does it make sense for me to do my own caching to free up memory, or can I rely on the OS and existing memory managers to do that for me?
Last edited on
It's not something I would overly worry about until you're in the 100's of MB.
Deeply nested undo information will likely find itself on disk just by virtue of not being touched in a long time, and this you get for free from the OS.
Deeply nested undo information will likely find itself on disk just by virtue of not being touched in a long time, and this you get for free from the OS.
sometimes large data can be a pointer to the current data, if it has not changed, and if the pointer is not null, you can assume it did change, that sort of scheme. For example an image where only its position or rotation or something changed does not need all the pixel data again, that part can be smoke and mirrored away. Maybe something like that can help, esp if the ui is tracking a bunch of simple things like positions that change frequently and the other stuff changes rarely...
I think you shouldn't care too munch, unless we really talk about massive amounts (e.g. several gigabytes) of data that can't normally fit into RAM. As others have pointed out, even if the system runs out of physical RAM, it will simply move "not recently used" pages to the swap file; and load those pages back into RAM if they are ever accessed again. You don't want to push the system into "page thrashing" though (which happens when memory pages are constantly moved in and out), because things will get extremely slow then...
https://en.wikipedia.org/wiki/Thrashing_(computer_science)
You probably want to limit the size of the "undo" stack in some way, either by the number of "undo" steps or by the size (in MB). You can use a ring buffer, so that the oldest data will be discarded/overwritten, once the maximum size has been reached. Also, do you make a full backup copy of the state for each "undo" step, or just store the minimal information required to reverse each change? The latter certainly would be a lot more complex, but potentially reduces the amount of data that you need to keep around.
https://en.wikipedia.org/wiki/Thrashing_(computer_science)
You probably want to limit the size of the "undo" stack in some way, either by the number of "undo" steps or by the size (in MB). You can use a ring buffer, so that the oldest data will be discarded/overwritten, once the maximum size has been reached. Also, do you make a full backup copy of the state for each "undo" step, or just store the minimal information required to reverse each change? The latter certainly would be a lot more complex, but potentially reduces the amount of data that you need to keep around.
Last edited on
Topic archived. No new replies allowed.