Community
Participate
Working Groups
The current save story consists of full saves when the method IWorkspace.save() is called and snapshots every 10 operations. The save() method is only called by the UI when shutting down the workbench and menu entry for save is not likelly to appear. It has some consequences: - the snapshot file keeps growing undefinetely - some garbage collection actions are not called We should rethink our internal save strategy. A better picture will show up when we start self-hosting. NOTES: RTP (4/9/01 10:50:48 AM) Include in the garbage collection all files that use the safe chunky streams. JM (5/13/2001 9:09:34 AM) The main issue here is that the snap files continue ot grow. It would seem that every N snapshots we should rip through and compress the snapshot files if we can. Certainly the markers and sync info files would be doable. The tree files may be harder. Moving to Candidates JM (02/06/2001 12:36:32 AM) JW has supplied code which supports time-based snapshots. Unclear if we have time to introduce this now. The current release has the operation count set to 100. This is somewhat high. Leave this as a candidate. JM (05/06/2001 6:10:55 PM) Include time permitting. Has some bonus behaviour though not without risk JM (05/06/2001 7:14:54 PM) Consider changing the snapshot number ot 50 or so. do not put in the timebased snapshot mechanism. Future enhancement. JM (05/06/2001 7:57:51 PM) RTP Change your value to 50 and run. the key is to look for place where snapshots are taking a long time and interupting the workflow. Use the .options settings to turn on snapshot tracing. RTP (6/6/01 4:04:37 PM) Its running fine, although I never got a snapshot time longer than 2 seconds. Also I do not use huge workspaces. JW (6/7/01 4:12:18 PM) 2 seconds is a significant interruption when stepping in the debugger (Every step is an operation). RTP (6/7/01 5:19:20 PM) If 2 seconds is bad, I've just got a 3.8 one.The workspace is the same. JM (6/9/2001 1:29:36 PM) Deferring. Leave snapshot count at 100. Do not include the time-based snapshot. Look at performance characteristics in the future.
PRODUCT VERSION: Eclipse SDK 0.042b
Closing this PR. A number of performance issues in this area have been addressed. Tree deltas are now periodically collapsed, resulting in smaller snapshots. I have been working for two weeks with resource debugging turned on in my self-hosting workspace, and I have never seen a snapshot longer than 800ms. More typically, it is around 150ms. This is reasonable considering it only happens every 100 top-level operations. This time will also be proportional to the size of the changes. So if you're just stepping in the debugger for example, snapshots will be small and fast. Snapshot files on disk seem to be reasonably sized after a day of development in the same instance.
