I second this. Same scenario, going from 2.6 to 3.1.
My file is 2.8M XML.

Could y'all report the file count in your data directory?  I've noticed anything above 150 or so is creating a noticeable problem, though it might be its own separate bug.

By file count in our data directory, I am assuming you mean where the .gnucash xml file is stored? I have 31 files in that directory.. mostly backup files.

Since the last time I posted. I tried running GNUCash on my work computer, and it opened and saved fine. No noticeable slowness. Because I store my data on onedrive, it was using the same directory structure.

Same version of GNUCash, My work computer is Windows 10 V1709
Where I am having the issue is on my surface, Windows 10 v1803 (I upgraded to 1803 before I upgraded to 3.1. 2.6 was running fine on v1803)



Thanks,

(In reply to Robert Chapin from comment #2)
> Could y'all report the file count in your data directory?  I've noticed
> anything above 150 or so is creating a noticeable problem, though it might
> be its own separate bug.

I have 91 files in that directory.  I also keep it in a subfolder of onedrive.  I downgraded to version 2.6.21 and the problem went away.

(In reply to Lee from comment #4)
> (In reply to Robert Chapin from comment #2)
> > Could y'all report the file count in your data directory?  I've noticed
> > anything above 150 or so is creating a noticeable problem, though it might
> > be its own separate bug.
> 
> I have 91 files in that directory.  I also keep it in a subfolder of
> onedrive.  I downgraded to version 2.6.21 and the problem went away.

That said I also tried moving the gnucash file to a separate drive and even a USB key before downgrading and neither helped.

I'm having the same problem with a 1.5M XLM file using Windows 10. After upgrading from 2.6.19 to 3.1, save time is much, much longer and sometimes doesn't finish. I have about 99 files in the subdirectory. Moved the file to it's own directory and it still saves very slowly.

Thanks Paul/Lee,
 Can you tell us if you upgraded to the most recent Windows 10? (v1803 that was just released a couple of weeks ago).

I am wondering if there is a connection.

(In reply to Paul from comment #6)
> I'm having the same problem with a 1.5M XLM file using Windows 10. After
> upgrading from 2.6.19 to 3.1, save time is much, much longer and sometimes
> doesn't finish. I have about 99 files in the subdirectory. Moved the file to
> it's own directory and it still saves very slowly.

Hi Keith,
I just updated to v1803 and have the same issue using v3.1. I notice that the save indicator at the bottom right makes the first round slowly (a few minutes or more), then on the second round, stalls at about 25%. I dropped down to v2.6.21 and now my save time is about 4 seconds.

Same situation. Windows v1803, upgraded to GNC 3.1, XML file around 1.5 MB, lots of files but removing them doesn't help, and super long save times compared to 2.6. Only difference for me is I haven't seen the cases where the save sometimes doesn't finish.

I am also noticing severe slowdown not only when saving but also when rendering reports, for instance. I don't know if the problem I am facing is the same as the one this bug refers to, but I found it might be useful if I shared my experience here.

Accidentally, I've noticed that this slowdown is proportional to the size of the GNUCash window: The bigger it is, the slower everything gets. As I usually run GNUCash maximized, I've been getting the biggest slowdown impact.

Now, whenever I want to save the work I've done, for instance, I first exit the "maximized window" mode and resize it so the GNUCash window is very small. Then I hit save, and it now finishes saving blazingly fast. Then, I go back to maximized window.

If I keep resizing the GNUCash window while the save operation is ongoing, I can see that its speed keeps varying according to the window size.

Maybe there is something that is triggering unnecessary full GNUCash window redrawing while saving?

My current display settings on Windows are 4K (3.840x2.160) resolution and 175% DPI scaling.

I can confirm that indeed the slowdown is proportional to the size of the GNU Window. If I make it as small as possible, it save quicker

Running GNUCash 3.2

(In reply to tmanhente from comment #10)
> I am also noticing severe slowdown not only when saving but also when
> rendering reports, for instance. I don't know if the problem I am facing is
> the same as the one this bug refers to, but I found it might be useful if I
> shared my experience here.
> 
> Accidentally, I've noticed that this slowdown is proportional to the size of
> the GNUCash window: The bigger it is, the slower everything gets. As I
> usually run GNUCash maximized, I've been getting the biggest slowdown impact.
> 
> Now, whenever I want to save the work I've done, for instance, I first exit
> the "maximized window" mode and resize it so the GNUCash window is very
> small. Then I hit save, and it now finishes saving blazingly fast. Then, I
> go back to maximized window.
> 
> If I keep resizing the GNUCash window while the save operation is ongoing, I
> can see that its speed keeps varying according to the window size.
> 
> Maybe there is something that is triggering unnecessary full GNUCash window
> redrawing while saving?
> 
> My current display settings on Windows are 4K (3.840x2.160) resolution and
> 175% DPI scaling.

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=795804. Please continue processing the bug there and please update any external references or bookmarks.