I think it's fair to say this is only true for a 64 bit app. In a 32 bit app, it's fairly easy to exhaust your address space if all deleted files are kept in-memory.
On 26 Mar 2012, at 00:57, Steven wrote: > Thanks for the info Graham. > I'm using NSUndoManager. I thought that many large objects in the stack > would cause memory pressure and would be better occupying disc space as they > are only needed at undo/redo time. Good to know that the VM system will take > care of it. > > Steven. > > On 24 Mar 2012, at 01:04, Graham Cox wrote: > >> You can read and write to the Application Support folder. >> >> But FILES in an Undo stack? That makes little sense to me. >> >> If you want to undo changes to a file, store the changes or the command that >> will cause the changes in the undo stack. If you are changing the >> organisation of files on disc then save a description of that organisation >> in the undo stack. You may want to read up on the way Cocoa utilises Undo, >> because it sounds like you might not have a good grasp on it. >> >> Even if you need to store very large objects in the undo stack, unless you >> can prove it's a serious problem, just let the memory get paged to disk VM >> naturally. It's rare that users need to undo a very long history, so even if >> the older history is paged out, the chances are the user will never know. >> >> --Graham >> >> >> >> >> >> On 24/03/2012, at 10:17 AM, Steven wrote: >> >>> Hello, >>> >>> Where is the correct place to store an on-disc undo stack associated with a >>> NSDocument instance ? >>> The stack may contain several potentially large files so we don't want them >>> to occupy memory. >>> For a compound document the stack could reside in a directory NSFileWrapper. >>> For a single file document should a temporary directory be used ? >>> I guess the chosen location may need to persist beyond the occurrence of >>> the automatic termination feature. >>> Any advice appreciated. >>> Thanks. >>> >>> Steven. >>> _______________________________________________ >>> >>> Cocoa-dev mailing list ([email protected]) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com >>> >>> This email sent to [email protected] >> > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
