I just lost another half an hour of work on a presentation. My fault, of course.
The problem is that once a presentation gets larger, even on a fast machine, a Save will take several seconds. That’s long enough to interrupt a work flow. Same about auto-save. The main reason I don’t have that on to save every 5-10 minutes is that it disrupts, seriously.
All that woe would disappear if we could have a background save, i.e., the program saving a snapshot of the current file in memory to disk, while letting the user continue editing it (with, those ongoing edits, obviously, not saved to disk at that point).
The same is true when working on a large spreadsheet.
Perhaps also for large text documents but I have not experienced this.
Still, perhaps this could be implemented across the suite? If not, Impress and Calc is where it would help me most.
You are not the only one, who is interrupted. See for example fdo#67487 or https://issues.apache.org/ooo/show_bug.cgi?id=88194.
More than desirable, but IMO maybe not a so easy task, as it seems. As you mention, this means that at least we need to do a complete copy of the snapshot, duplicating the file in the memory for gain time, (save to disk maybe is slower than save the odf file because is much higher) and save the copy in a parallel/background thread to disk, as I know at the moment not developed, you can’t save a file and working in other at the same time.
On Linux it ought to be reasonably simple. Linux’s memory uses copy-on-write, so simply fork the program, and let the one process save the state. The only extra memory used will be any changes done while saving. Whether Windows/Mac also have copy-on-write I do not know.