Cherrytree: Improve saving performance/experience (C++)

[ForeverRainbow]

Hi
This is possibly something which can wait until after the C++ port but is something I have noticed when saving even smallish trees (~5 nodes or more): The UI freezes.

I think this is related to #777, which speeds up load times but not save times, as an example saving ~50 nodes (after importing) took almost 5 seconds in which cherrytree was completetly unresponsive

A possible quick workaround for this I think would be to just do the saving on a separate thread, there would have to be locking for XML files and something to prevent cherrytree closing while it was saving but it should not be too difficult (actually I am quite surprised that the saving _is_ on the UI thread right now)

[txe]

I cannot reproduce it, 100 nodes (though it's mostly a text) saves/resaves without any issue. I used virt. machine with 2 core and not much memory. Everyone would be notice such issue with 5 nodes.

[ForeverRainbow]

Mine is just text too... that is strange. Currently ive only tested it with nodes that have been imported (overwise I have to edit all the nodes) - It does not have any issue saving nodes if they have not been edited ofc it only does that if I have multiple unsaved nodes

Edit
The UI freeze for me is short but noticable with 5 nodes, its only once things start getting bigger that it becomes a big annoyance but it is possibly something up with my setup if you cannot reproduce it

[metal450]

I'm noticing a UI lag not while saving, but prior to quitting. i.e. if Auto-Save is off & I quit, the UI locks up for 5+ seconds before it prompts me for whether or not I want to save. Not sure if it's the same issue, but seems like it might be related? On Windows.

[txe]

@ForeverRainbow, if the issue is still presented, you can try one of the following things:

• under debug, step over the saving function to see if it is actually slow or fast
• press save in cherrytree and then pause in debugger to see callstack. Probably, it will help with figuring out what place is slow.
• you can give me a step-by-step description to reproduce the issue for sure, I'll try to fix it

[ForeverRainbow]

Update on this, just tested it again with ~15 unsaved nodes (5 tables, no text), it is only an issue when using SQLite, XML saving happens almost instantly - the SQLite save took 2-3 seconds.

[ForeverRainbow]

To reproduce the issue, at least on my machine:

1. Open a new instance
2. Save it in SQLite format
3. Import a bunch of nodes, at least about 10 or so (with or without widgets)
4. Hit save and count

[ForeverRainbow]

@txe Is there any reason why the saving _can't_ be made multi-threaded? Cause I could give a crack at it if there is nothing major

[txe]

Nothing prevents using multi-threads, I just want to know what the root of the issue is before using the hammer.

[DiagonalArg]

Ok, I'm having the same problem, also with the SQLite backend. I am seeing the UI freeze for 20 seconds, and the time is growing as my note size grows. I posted this issue in #854

[txe]

@ForeverRainbow, I tested

• saving 200 nodes with a lot of text, no issues
• saving 100 nodes with tables, no issues
• saving 60 nodes with images, it's slow

Turns out, taking buffer from image (pixbuffer) to save it in db is quite slow. So far I see two solutions:

• always keep buffer with image. Pro: simple, Cons: 2x memory. Synchronization (buffer-image) shouldn't be issue.
• Before saving, run multi-threads to take buffers (we know which nodes and images needs to update) and put it in cache, then use data from cache during saving. Pro: not hard to do. Cons: it's only faster by number of threads.

Any other ideas?

[txe]

@ForeverRainbow, I'm still confused by your words

Import a bunch of nodes, at least about 10 or so (with or without widgets)

That it can be slow without widgets, I couldn't reproduce it, are sure?

[txe]

Well, you said xml saving is fast and sqlite is slow, thus taking buffer from image is not your issue.
@giuspen , when you have time, can you repeat this:

Open a new instance
Save it in SQLite format
Import a bunch of nodes, at least about 10 or so (with or without widgets)
Hit save and count

[giuspen]

@txe I was trying on msys2 today for the spell check languages and even without importing nodes the UI felt slower than the Pygtk2 version, lagging too much. I will help looking into this later when have more time but I would not give top priority to this, I'm sure we'll sort it out!

[txe]

Well with msys2 it's not surprising, even compilation is 3 or 4 times slower there than on linux.
I hope you don't have these lags on linux otherwise it's just crazy.

[giuspen]

No my report was msys2 only, haven't seen lag issue on Ubuntu 20.04

[DiagonalArg]

@giuspen - as mentioned in the issue I posted above (#854), I'm on Ubuntu 16.04 and the freezes are bad enough on big notes that it becomes hard to use.

[txe]

@DiagonalArg , it was about another issue, I'm working on your issue, don't worry.

[ForeverRainbow]

@txe This _may_ be related to #861, although I am not sure, if it is caused by the pointer arithmetic then before it would just be filling it with junk or crashing or god knows what anyway. I have just been testing it with a clean config and I am getting less than a second save times even with 50+ nodes. So it is possibly the config, something weird on my end which fixed itself, or something else but this issue seems to have fixed itself for now.

[ForeverRainbow]

@txe I think the second option (caching the images during saving) is probably better, 2x the size can be big for a node full of images. Also the con of only being faster by number of threads is true but once its off the UI thread then save time is not such a massive priority, even if its save on close cherrytree can ghost until its done saving

[txe]

Closing this issue which was caused by config.cfg file. It was fixed by checking some conditions during reading the configure file.
About concurrent saving images, I added PR #928