#204 Xournal becomes sluggish for moderately sized notebook

[Max]

Hello,

I noticed that Xournal becomes very sluggish for notepads that consist of ca. 15 pages or more. Every few seconds, Xournal will freeze when I am writing and the "ink" will appear some seconds later which is a major annoyance. The freeze is not limited to the ink, the program stops responding in that case (so menus are not working etc.).
Of course, I am willing to participate in debugging, I might be able to profile the application to find the expensive function(s). Also, I am happy to provide the notebook in question!

[Max]

I did some digging on this one, it's looks like a rather clear case to me!
I ran xournal with gdb and stopped when it hung - most of the time, it hung in save_journal.

I have the following suggestions:
1) Move (auto)saving to a different thread (effectively seperating UI from the rest, which is a good thing). Might be difficult if Xournal uses a lot of RAM..
2) Zipping the file also costs much time - only do that on a final save, not in autosaves.
3) Make the file modular (that is: only save modified pages since the last save).
4) Only save incremental updates in the autosaves - do a proper save in a final save.

What do you think about those ideas? Which might be the easiest to implement (with the current Xournal architecture in mind)?

[Denis Auroux]

Really, the simplest practical thing is to increase the auto-save
interval. Perhaps this is misguided on my part, given that not all
distributions are equally stable, but the goal (which should be close to
realized if you are up to date with the git repository) is that xournal
just shouldn't ever crash. So, you shouldn't need frequent auto-saves,
or perhaps any auto-saves whatsoever if your system is stable and you
are not prone to inadvertently running out of battery.

That said: your suggestion #2 (not compressing the autosaves) is easily
feasible, the others require a lot more work.

3 and #4 are hard because the xournal data structures don't keep track

of what is saved or not, either the document is saved or it isn't but we
don't have more refined information. Marking individual pages saved or
not should be fairly straightforward, though, so saving only the
modified pages in the auto-save should be feasible; it has the drawback
of requiring some work on the file format / algorithm for loading
auto-save files.

Autosaving in a separate thread is a either a hack (and I'm worried
about reliability) or a huge project. To easily avoid conflicts,
basically we need to hold off on any operation that modifies the journal
until saving is completed, in which case we're back to square one -- you
can't draw while saving is in progress. Or we need to lock data
structures etc but this complicates a lot of the code. Or one could try
to make it possible to draw while saving is in progress by being careful
about inserting the new strokes atomically into the journal in a way
that can't mess up the save in progress, and block other operations, but
it's an evil hack.

Very long-term, of course the whole code needs to be rewritten from
scratch to achieve modularity and separation between UI and internals,
but there's a lot of work, and I don't foresee being able to do this in
the near future.

Denis