撤销/重做框架中的内存管理

Question

I am in the process of implementing undo/redo functionality for a segment of my software developed in C#. The data on which the undo/redo operation occurs is stored as a list of objects List<MyClass> . The size of the list can become large (>1k) in certain cases.

I want the user to undo/redo as many times as they possibly can. But if I simply store all the previous states (as in a Memento Pattern) it might lead to the software using up too much memory, which I do not want.

The list of solutions I have come up with are:

1. Store the states in a file somewhere and only read a few states at a time. That way I won't use up a lot of RAM but reading and writing to a file might be time-consuming (probably have to run it on another thread).
2. Calculate the delta between two consecutive states and store that instead. For example, UNDO: DEL LIST[5] & REDO: INSERT <object> LIST[5]

What are some other efficient ways to implement undo/redo functionality and how do they compare to the solutions above?

Answer 1

My preferred approach is to use different stacks for different sections of the application, and aggregate them together. I find this to be very efficient. I released an open source project implementing this approach - https://www.nuget.org/packages/UndoService/

I've used this approach in conjunction with your first suggestion. When a background image is changed in my app, it just stores the Id, and loads it from disk as required. Other objects use less memory, so their whole state is just stored on a stack in RAM. The undo service uses delegates to access state and generic stacks so it's pretty simple to mix approaches like this.

I've previously used a common approach based on the same concept as your second suggestion. This was to use the Command pattern with an Undo() method defined in the Command interface. In terms of resources during execution, this is a very efficient approach because it doesn't need to store state at all, only the commands. However, I dropped it in favour of Memento because of the additional development time and complexity it involved. That said, it would be a good fit for some projects, especially where the number of commands is not too great or the memory imprint of the application state is significant.