Problem with AutoSave module

Support
1

Hello,

How can I prevent the Slicer main window from becoming unresponsive when using the autosave feature? I’ve observed significant lag in the main window after enabling autosave. Is it running on the same thread as Slicer?

Few suggestions on autosave:

  1. Since CLI modules run on a separate process, and I came across a commit mentioning running at least two CLI modules parallely, So can we run autosave as a CLI on a separate thread to prevent the main window from getting stuck?
  2. Alternatively, can we utilize the ParallelProcessing module to run autosave in a separate process? (I’m concerned about whether this handles synchronization between scene saving.)

Lastly, is there a way to integrate QtConcurrent into Slicer? I attempted to add it, but it didn’t work at all.

2
  1. AutoSave is a Python module so it cannot make use of the methods applicable to CLI.
  2. If you use ParallelProcessing you do not have access to the Slicer MRML scene, only data you may have saved yourself before starting the process. Since it is the saving itself that takes time, and causes the lag, it is not something that can be outsourced to a parallel thread. Note that I say this with my limited knowledge about both modules.

Maybe you can limit autosaving to the MRML node types you are interested in autosaving? Or limit the types of events that trigger it?

3

For my use case, I would like to save the entire scene as a bundle. Incremental saving would also be acceptable if it is applicable in the slicer.

How about re-implementing it as a C++ CLI or Loadable module? Is it a viable option?

Additionally, what are your thoughts on using shared memory for data saving?

4

I think a lot of the slowness is caused by the single threaded compression of the bundle, particularly if the data is large or there are many volumes in the scene. I wonder if it is possible to create the bundle without compression.

5

It looks like the current AutoSave only saves as MRB, so it’s always saving the bulk data (and compressing it) without regard for the modified status. Someone could look into saving incremental .mrml files to avoid this overhead for cases where the bulk data isn’t actually changing and can be restored if there’s a crash.

1 Like
6

I experimented with it, and I found that scene saving is taking place on the same thread as the slicer. That’s probably the reason for freezing.

7

That can probably be achieved if there is a way to determine whether a scene has been updated and also retrieve its state, including the source of the update. This would allow us to save incremental updates from the last modified state to the current state.

8

The ModifiedSinceRead property should be reliable. It’s used in the Save dialog to determine which nodes need to be enabled for saving by default.

1 Like