Multiple Undo devours RAM
Multiple Undo devours RAM
- Subject: Multiple Undo devours RAM
- From: Erez Anzel <email@hidden>
- Date: Mon, 26 Jan 2004 20:22:11 -0500
I want to have my cake and eat it too: limitless multiple Undo, without
eating up more and more memory. Perhaps by optionally managing the Undo
and Redo stacks on disk instead of in memory.
I have been happily using NSUndoManager in my Cocoa Objective-C++ app,
after having fashioned my design after Bill Cheesemans Vermont Recipes
(thanks, Bill). But my users seem to have a penchant for large data
files.
When a user imports fifty thousand data points (common in my CAD-like
app), then moves them, and moves them again, and does a variety of
operations on them, deletes them, imports others, etc., I record it
all. (I do clear the Undo stack when the user saves.) But theres a
massive overhead to this: not only are my objects saved, but the Undo
chain itself seems to have its own significant luggage.
To add to the mess, each primitive set method creates an NSDictionary
instance to post to the NSNotificationCenter (which I assume is
autoreleased, along with the entire message). One move can give fifty
thousand messages. Likewise, one Select All or one click to deselect
all. And I figure that none will be released until the end of the event
loop, meaning all of them exist at once.
I know that a number of operations can be undone by storing a
collection of pointers to the objects along with the previous state of
each object as it relates to the specific user action. But that means
having to mess with the current, clean approach which I implemented.
I figure that instead of storing the Undo and Redo stacks in memory, as
is currently done, perhaps theres a means of writing them out to disk.
There would be some overhead for each operation, obviously. Perhaps
this could be an option for the user. Or perhaps the hard drive is used
if real RAM starts getting tight, so as to avoid getting bogged down
with virtual memory.
Any suggestions? I'm looking for a reasonable diet plan.
Thanks...Erez
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.