recently updated to 3.1 from 2.6 and it now takes forever to save, almost 6 minutes for a 32M XML file. I have tried compressed and uncompressed but it doesn't help.
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.
I've also found this to be tied to the window size / resolution. If I override the HDPI scaling and have windows manage the scaling, gnucash runs way faster, similar to my desktop that doesn't have a high resolution display. I also noticed that before the change, the display would get screwy or go completely blank with more than a few reports loaded. The overall response was similar to the saving issue, if I reduced the window size I could load more reports before the display crapped out, and with the HDPI scaling overridden, I'm not seeing the display issue anymore. The graphics are a little blurry with the default windows scaling (as you might expect), but it is still much better than having ultra slow saving and only being about to load a couple reports at a time.
Interesting. Is everyone here using a HiDPI monitor? Rafael Medina, what do you have set in Settings>Advanced Scaling settings and on GnuCash's Properties (Start GnuCash, right-click the icon in the taskbar, right-click GnuCash in the menu, select Properties from the second menu)? What did you change to improve GnuCash's performance? The only thing that should cause redraws is the progress bar, and of course it should cause redraws only for the little bit of the window that it occupies, not the whole thing. Does dragging another application's window in front of GnuCash make a difference? What if you cover the progress bar?
Yes high DPI I set the high DPI compatibility to override, scaling performed by system (blurry) because the reports were showing up tiny and that seems to have also addressed the saving performance.
Hi John, In Advanced Scaling, I do have it turned on. But turning on and off does not make a difference. I did try a couple of things while saving. If I try to cover the window with another window or just cover the progress bar, nothing is different. But if I minimize the window it saves at a normal pace. (even faster than if I were to resize the window to its smallest) And as already stated, as I make the window smaller, it saves more at a normal pace (and this is on the fly.. as in I can save .. then resize the window and watch it speed up or slow down as I make it smaller and larger.)
Keith, That's interesting. I wonder why your experience with scaling settings differs from Rafael's and Geoff's. If covering the window with another doesn't work I guess that means that Windows is still drawing to a backing store.
Ya, I am not sure. I do not use reports, but when I view reports (Budget Balance Sheets for example) it does not look any more or less blurry with the scaling setting on or off. Unless I am not using the right setting? Fix scaling for apps I turn on and off the 'Let Windows try to fix apps so they're not blurry' setting. Makes sense windows is still drawing to the backing store because taskbar preview works whereas if I minimize it, it only shows the last screenshot before it was minimized.
There's an additional per-application setting in Properties>Compatibility. Instructions to get to it are in comment 13.
Ah.. ok. So if I override the high DPI Scaling and choose 'System' (options where application, system and system (enhanced)' then it does save quicker. I think when I minimize it still saves it quicker.. but really hard to tell because you can not see it saving.. so if it is quicker.. only by a hair ;)
OK. I think that pretty well confirms the work-around and indicates the root cause or perhaps causes of the problem. It's apparent that there's a problem in the Gtk or perhaps Cairo drawing code that's causing the whole window to be redrawn when only a very small rectangle should be getting invalidated. That's compounded by Cairo's mismanagement of HiDPI scaling. Neither of those are anything that GnuCash can fix, but we can add a registry key to the installer to turn on the work-around. Should we? How bad is the loss of sharpness?
It's no worse than the way 2.6 looked. It's just slightly dispiriting that updating to the more modern Gtk still does not work well with high DPI screens ;-) The only thing I noticed is that the column widths on the transaction register tabs became twice as wide but I'm not sure if that was just because I used to use it without scaling and now some persisted geometry settings are now wrong, or if it's actually gonna stay that way even if I resize the columns manually.
While researching this I encountered a blog post from last year saying that Gtk "finally supports Windows HiDPI". Unfortunately for Gtk4, which doesn't seem close to getting a production release. Even when it is we won't be able to use it until we figure out a way to do reports without WebKit because it's not being maintained for Windows anymore. You may indeed need to apply some styling to get things to look right. Once you figure it out please add your adjustments to https://wiki.gnucash.org/wiki/GTK3.
(In reply to John Ralls from comment #13) > Interesting. Is everyone here using a HiDPI monitor? > > Rafael Medina, what do you have set in Settings>Advanced Scaling settings > and on GnuCash's Properties (Start GnuCash, right-click the icon in the > taskbar, right-click GnuCash in the menu, select Properties from the second > menu)? What did you change to improve GnuCash's performance? > > The only thing that should cause redraws is the progress bar, and of course > it should cause redraws only for the little bit of the window that it > occupies, not the whole thing. Does dragging another application's window in > front of GnuCash make a difference? What if you cover the progress bar? I changed the "High DPI scaling override" setting from "application" to "system" and that fixed my issues. I didn't try saving while moving other windows around, but I didn't notice any change to the display issue that seems related. I'm not too surprised by that as I think from windows 7 onward each application window is drawn independently and then all of them are composited together by the window manager to do taskbar thumbnails, aero effects, etc. The blurriness is relative, on it's own it isn't too bad, but side-by-side with applications that make use of the HDPI screen you can see a noticeable difference. Definitely a reasonable trade-off to fix the saving/display issue, though it would be great to eventually fix
*** Bug 796835 has been marked as a duplicate of this bug. ***
I have replicated this issue and workaround on my system: Issue: - Extremely slow save times. Resolution: - Set "High-DPI Scaling Override" to "System" System Information: - GnuCash: Version 3.2 Build 2018-06-24 - OS: Windows 10 Home, Version 1803, Build 17134.228
I found this registry setting (don't remember where now): Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers String value {app}\bin\gnucash.exe "~DPIUNAWARE". Please try that out after turning off whatever overrides you've set in properties. If it works I'll put it in the installer for 3.3.
I tried looking for that registry key. I could make it as far as: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags Beyond that, there was no "Layers" level. Was this key already set for you, or did you create it?
I created it and I expect that you will too.
If I understand this bug correctly, re-draw calls into cairo are likely slowing things down during a save-operation becuase of the update call's to the progressbar...forcing more stuff to redraw then it should. Does this happen with auto-save? Is is possible to just send less redraws to the progress bar to help plug this bug? For example I used gdb and stopped on the gnc_window_show_progress callback() during a save, and noticed it gets called every few percent (3, 5, 7, 11). If that is too often that is causes slowness in saving --> what if we made it more course by calling the cairo calls less often (courser progress bar, but at least it saves quickly.) thoughts? -Nate
Worth a try. Can you build?
I'll give it a try. Im on ubuntu, so doubt I'll see the speed issue, but can verify it doesnt break pre-existing functionality at least.
Created attachment 373028 [details] Test Patch to do less cairo ops for progress bar. This is a test patch which basically addss lines in the progress bar update callback for saving, to prevent it from running for each time it gets called. Basically I have a lower range and upper range (in percentage) which will allow the callback to run, and for percentages in the middle it basically updates in 20% increments.... It will make the progress bar more choppy but it might speed up saves on windows machines because it does less write-ops to cairo.. I only tested that it doesnt break my ubuntu bionic beaver build. Didnt have a build setup on Windows. -Nate
On Windows 10, saving is very very slow for 3.3. Speeds up dramatically if I reduce the Gnucash window to as small as possible while saving. Altering HiDPI settings via taskbar icon properties as discussed above has no effect.
(In reply to davethegeo from comment #33) > On Windows 10, saving is very very slow for 3.3. Speeds up dramatically if > I reduce the Gnucash window to as small as possible while saving. > Altering HiDPI settings via taskbar icon properties as discussed above has > no effect. Did you try running a built version with my patch? -NAte
I did not try it. I'd love to, but I have absolutely no idea how to. Dave
I am experiencing the same issue. Just upgraded to the latest stable release (3.3+, 2018-09-29), and it takes well over 5 minutes to just read or save the user data. I rolled my version back from backup to 3.0, which appears a bit faster - but still painfully slow. Reverting back to 2.6.13, loading and saving takes under 10 seconds. I am on OSX 10.11.6. my datafile is 1.1MB (compressed), and lives in a directory with 20-odd files (mainly GnuCash auto-backups). I haven't found that changing window sizes, as reported by some here, have any effect - presumably b/c I am not on Windows; also, just reading the user data at startup, when only the splash screen is rendered, already shows this issue. Hoping this can be addressed somehow, b/c it is really affecting the usability of GnuCash; and I have close to 20 years worth of data in it (been using GnuCash since it was still xacc). I'll have to stick with 2.6.x for the moment.
Good luck Alex. I've tried John Ralls suggestions but not sure if I have the correct name of string value. Name is /bin/gnucash.exe and data is ~DPIUNAWARE . Anyway, it didn't work. Would like to try Nate's patch but I'm not a coder so I'm stuck for now. I'm running v 3.3 2018-09-29.
There is more information over on http://gnucash.1415818.n4.nabble.com/GNC-Windows-10-installation-very-slow-opening-or-saving-file-td4700632.html I posted this: I had the same issue with Windows 10. Very slow loading and saving. I went back to 2.6 and everything was good. Saving with 2.6 took around 8 seconds. With 3.2 took close to 40 seconds to save. I then made the window as small as I could and it would save in about 12 seconds. So based on that last message it may be repeatedly updating the window. Probably to update the progress bar.
I am new to this system. but using GnuCash from 7 years. i had to go back to 2.6 as well as latest is very slow in saving in windows system. why this issue is in need-info. many people have reported and this is easy to reproduce.
Version: 3.4 Build ID: 3.4+ (2018-12-30) Windows 10 I have the same problem, saves really slow, I first thought it was hung, but now tested to make the window smaller and the saving is faster with a small window just like others have reported.
After reading about speed improvements in version 3.5 from the GnuCash - User mailing list I installed 3.5 to test. I have previously tested versions 3.1 - 3.3 and had experiences extremely slow saving, so much so compared to 2.6.21 that GnuCash was unusable to me. Version 3.5 is for me much faster. I don't have any times for 3.3 to compare but it took easily more than twice the time than 2.6.21. However I can compare 2.6.21 to 3.5, for loading, saving and running a large transaction report. Load Save Txn Report ---- ---- ---------- 2.6.21 29s 9.1s 1m 03s 3.5 10s 3.5s 31s This is Windows 10 Pro x64.
Still having issues with version 3.8 windows enterprise 10.0.17763 and high DPI 4K displays. If I maximize GNU cash the save will essentially stall. The progress bar will move few pixels every minute. The only work around I have found is to reduce the window size as small as possible, less than 1/4 of the screen. This increases the save speed about 100 times and the save will complete in a few seconds. I have tried the High-DPI Scaling overrides but no of them help the issue. Small window (1660 x 900) save time 8 sec Large window (3840 x 2160) save time 12 min 20 sec
At some point this "slow save" issue with high DPI screens got fixed, and it was fixed through Gnucash 4.2-1. It broke again in Gnucash 4.3 and is still broken in Gnucash 4.5. As before, resizing the main window to be small causes the save process to speed up significantly. The smaller the window, the faster saving completes. I'm on MacOS 11.2 w/ a 5k Retina display.
@lairofthewalrus, You're the first person to report this on macOS. How big is your file, what backend are you using, and what are the comparative times? I trust that you are (or will be) comparing the two versions one after the other on the same macOS release.
(In reply to John Ralls from comment #44) > @lairofthewalrus, > > You're the first person to report this on macOS. How big is your file, what > backend are you using, and what are the comparative times? I have a 2.8MB compressed accounts.gnucash file using the XML backend. I am comparing Gnucash 4.2 to Gnucash 4.3 on the same Mac. I add one transaction to an account and then click save. V4.2 takes 4 seconds to save, while V4.3 takes 27 seconds. It also doesn't matter if Gnucash is on a standard DPI display. I can move the window to my 1080p display, and the issue persists. In the course of additional testing, I've found that the slow save time only occurs under a certain condition: only when an account tab is open and in focus for an account that has many thousands of transactions. If I start saving with such an account in focus, the save progresses slowly. Workarounds I've identified: 1) While the file is saving slowly, I can switch the focus to another account tab that has very few transactions, and the save immediately speeds up and completes within a few seconds. 2) While the file is saving slowly, I can resize the Gnucash window to be as small as possible in the OS, and the save speeds up and completes within a few seconds. 3) If I start saving while focused on an account tab with few transactions, saving completes within a few seconds. 4) If I make the Gnucash window as small as possible in the OS, saving completes much faster than if the window is zoomed to occupy the entire desktop. So the slow save time is dependent on: 1) An HDPI display in MacOS (but Gnucash could be open on a non-HDPI display) 2) Gnucash >= 4.3 3) Gnucash window zoomed to full size 3) An account tab in focus that has thousands of transactions
Thanks, that's really helpful.
I'm able to mostly reproduce your findings. Mostly because I can reproduce on both on my Retina MBP and my 2013 Mac Pro without Retina, so at least on macOS HiDPI has nothing to do with it. I'm also able to test something you're not: GnuCash 4.2 vs. later with the same build environment. That doesn't produce a difference, meaning that the full-screen, register with lots of transactions (my test file is 4.3MB compressed and the register that's slow has around 6600 transactions) difference between 4.2 and 4.3 is due to a change in some dependency or in the Xcode version. I hope it's a dependency, that will be easier to deal with and might also apply to Win32.
Bad news: The difference is due to Xcode upgrades. When built with Xcode 11.7 (the macOS 10.15 version) it takes about 6 seconds to save my file. The same version of everything built with the current Xcode 12.4 takes 130 seconds. The extra time is all in running the event loop to get updates to appear on the progress bar. I haven't worked out exactly what's going on, and may not be able to because I don't have the sources for the Apple code in question and I doubt my ability to reason it out with just disassembled code. I should be able to do a band-aid fix by updating the progress bar less frequently. That should help on the Windows side too; a macOS-specific fix in Gtk/GLib won't help them at all.
I've pushed a commit that updates the progress bar only when the percentage changes by at least 1%, so no more than 100 times instead of once per transaction. That reduces the large-file save time on macOS back to around 9 seconds. It has the added advantage of doing the same for load time. This will be in tomorrow's nightlies and GnuCash 4.6.
