Difference between revisions of "Speed Up Save"
m (→Performance save, background thread) |
m |
||
Line 40: | Line 40: | ||
== What About Auto Save == | == What About Auto Save == | ||
Auto save can be handled similar with above way, even the progress bar is unnecessary. User doesn't want to know when happens auto save. | Auto save can be handled similar with above way, even the progress bar is unnecessary. User doesn't want to know when happens auto save. | ||
+ | |||
+ | [[Category:Performance]] |
Revision as of 02:17, 7 March 2009
Contents
Current Save Flow
The current save flow is shown in the follow chart.
- Lock UI, ready for parameters and progress bar.
- Save data XMLs and media files into local temp directory as temp files. During this period, generally, save big content.xml and large media file is quite slower than others.
- Pack to zip file, still in temp directory.
- Copy the temp zip file as destiny file which is possible in network. The speed of this depends on the file size and the destiny location, local or network.
- Do clean work, send events, finish progress bar and unlock UI, user consider this as save finished.
What User See
Think about whar user see when saving document:
- UI locked, indicate OpenOffice start saving and can't edit now
- Progress bar is running, it is during saving
- UI unlocked, enable editor again, saving finished
After saving finished, user will do:
- Go on edit(generally, frequent)
- Close current module(if it is the only instance, close the program, happens)
Because current save implemetation is sequentially sharing the main thread, so when the document is large, UI seems blocked a long time.
Make It Seem Be Fast
If the document is large(XML file is large, or picture is large, or both), then UI will be locked for a long time, seems it is blocked. User jugdes wether saving is finished or not only by UI locked or not, but not the doc is really saved into the old file or not.
So making UI unlocked fast will come to a fast saving impression.
What We Can Do
On solution is unlocking UI early when we gathered essential data to save, but not after all data saved locally and transferred. This will happen after saved meta.xml and others and before saving content.xml and media files like pictures. And the left action can be put into a background thread to fulfill the task.
The slow operations are mostly moved into background, this will let user feel much faster than before. Even if user closes the program, OpenOffice will wait until the background thread finished. So the data is safe.
The “content” could be modified during background saving, so we can get a model copy when start saving. Some other conditions like two save task conflict can be solved by other methods.
What About Auto Save
Auto save can be handled similar with above way, even the progress bar is unnecessary. User doesn't want to know when happens auto save.