mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-16 07:04:23 -05:00
[GH-ISSUE #4045] [Bug]: Performance - adding / removing budget items very slow #116095
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#116095
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @quarklark on GitHub (Dec 26, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/4045
Verified issue does not already exist?
What happened?
With a larger files, the application becomes very slow to load at various points.
Specific points I've seen are:
How can we reproduce the issue?
Expected: The category is added right away.
Actual: The application appears to do nothing for 10-20 seconds, then adds the category.
Where are you hosting Actual?
Desktop App (Electron)
What browsers are you seeing the problem on?
Desktop App (Electron)
Operating System
Mac OSX
@quarklark commented on GitHub (Dec 26, 2024):
Presumably this is because the entire db needs to be loaded to perform each action. I imagine that fixing this would mean refactoring to lazy-load where possible, and add loading states, though I've not looked into the codebase much myself so this is just a guess.
https://github.com/user-attachments/assets/b3146e4e-7cc6-456d-b451-4cad9d6d5f94
@youngcw commented on GitHub (Dec 26, 2024):
Try resetting the budget cache
@quarklark commented on GitHub (Dec 26, 2024):
Trying this now - any idea how long it should take? So far it's been about 30min & it's still spinning?
@quarklark commented on GitHub (Dec 26, 2024):
1hour in, still working. I restarted the app, which loaded like normal (~15 seconds on load screen). Still having the same issue.
@youngcw commented on GitHub (Dec 26, 2024):
Hmm. Something must be off. If you are using a server try redownloading. If not try exporting and reimporting.
@quarklark commented on GitHub (Dec 26, 2024):
Any estimate on how long this process should take? It's currently importing, and has been spinning for ~8 min...
(I'm on an M2 Mac w/ desktop app)
@youngcw commented on GitHub (Dec 26, 2024):
Should be fast. I wonder if something is not happening right for M2. There is a build for Mac Arm, but maybe it struggles on M2
@quarklark commented on GitHub (Dec 26, 2024):
Yeah that seems possible. For reference, I was using the Arm build before, and just tried the X64 version, and it's even slower. (Works, but is worse.)
@quarklark commented on GitHub (Dec 26, 2024):
Looks like I'm having the same issues running from source with
yarn start- I'm unable to import my file; it just spins forever. (At least, it's taking an unreasonable amount of time.)@quarklark commented on GitHub (Dec 26, 2024):
Ok - ruling out platform. I'm seeing the same issue on a new PikaPods instance after importing my file.
@youngcw commented on GitHub (Dec 26, 2024):
Maybe try resetting the cache after importing each account to see if that fixes it. You shouldn't have issues with the number of transactions you claimed unless you are an order of magnitude above what you originally said.
@quarklark commented on GitHub (Dec 26, 2024):
I'm not sure I've ever been able to clear the cache properly. Looking at the file, the cache is absolutely huge:
Whenever I try the "clear cache" operation in settings, it just spins forever and never completes. I've yet to try leaving it overnight, but either way, something's not working as expected here. I've also tried loading the file without the cache, since I assume it would rebuild it, and it just ended up making the same thing.
@nonsleepr commented on GitHub (Dec 28, 2024):
Somewhat related issue.
I'm using
actualpyto import ~22k transactions to the server running inside a docker container. Commit stage clocks at 3h45m and counting.@youngcw commented on GitHub (Jan 10, 2025):
That cache is really big. If you have not already try the reset sync id option. That will collapse all the sync messages into a an updated file without all the overhead of the new messages.
@andyslucky commented on GitHub (Jan 15, 2025):
I am confused why several people have stated "should be fast" in their comment. Can anyone offer proof in the source code that the persistence layer is well-optimized? Doesn't this project use an embedded, single file based database? If that's the case I would say high-performance should not be expected here (without alot of optimization).
I have seen similar performance issues when applying templates (takes upwards of 16-20s to apply a template).
I have 4 local accounts with about 500-600 transactions in total (about 14 months worth of transactions in 1 account followed by a month or two in the others). At this rate, this application will be unusable within the next year.
@Teprifer commented on GitHub (Jan 15, 2025):
I have a hair under 7k transactions going back to 2017 (I imported from, YNAB). Applying templates to the whole budget(~40 categories) takes ~<1 second.
The suggestion from youngcw to reset sync id solves most reports of slowness, have you tried that yet? If it persists consider opening a support thread in discord.
@johnnysbug commented on GitHub (Feb 14, 2025):
I am also experiencing incredible slowness. I am running the client in an Edge web browser on a M1 MacBook Pro. The server is on my NAS in a docker container. I am running the latest version. I'm happy to provide any further details. Our budget data contains roughly 10 years of history. I have tried resetting the cache, but it didn't seem to make a difference.
@youngcw commented on GitHub (Feb 14, 2025):
Have you reset the sync id? That usually speeds things up if you just did an import
@johnnysbug commented on GitHub (Feb 14, 2025):
Just reset the sync id and that did speed things up quite a bit. Register updates were taking 10-20 seconds previously, and now seem to take around 5 seconds. I'm planning to start fresh so hoping by archiving years of data that will help improve this further.
@johnnysbug commented on GitHub (Mar 1, 2025):
Here's some more details on the extreme slowness of updating an account register. This is still occurring after updating client and server versions to
v25.3.0I've reset the sync id several times since initially experiencing this. It seems to alleviate the problem for a short time, but the slowness seems to accumulate the more register changes I make. This appears to be magnitudes more slow on my M1 Macbook Pro running in an Edge browser versus running on Safari on the iPhone. I have yet to try Safari on the MacBook, but will give that a shot later.
I made a video of updating an imported transaction where I change the payee name, remove the description and select a category. 50 seconds after modifying the payee name, it prompts me with the option to merge the payee, which I select to merge. Afterwards, it's probably another 20-30 seconds to see the description changes apply (in the video you can see the original description appear and disappear a few times), and then about the same time for the caegory change to take. Then close to two minutes in, I see the server syncing the changes.
Let me know if you'd like the video posted here or elsewhere.
@johnnysbug commented on GitHub (Mar 4, 2025):
I have since switched to using Safari and the performance is a fantastic improvement. No lag or delay at all. Just wanted to mention if anyone else is using Edge (or possibly another chromium based broswer) on a M1 MacBook.
@timschlechter commented on GitHub (Jul 4, 2025):
I had around 10 years of data, totaling approximately 23,000 transactions. However, Actual became unbearably slow. I removed 5 years' worth of data, leaving me with about 13,000 transactions. Since then, it works like a charm again.
Although this solution works for me and has improved performance, I do find it unfortunate that I no longer have the historic data in my budget file. It would have been useful for future comparisons and insights.
@smseidl commented on GitHub (Aug 11, 2025):
I created a link on Discord for similar issues: https://discordapp.com/channels/937901803608096828/1404310599390724197. For me I'm finding very high CPU Spikes for any change in the budget screen.
@joel-jeremy commented on GitHub (Aug 20, 2025):
This might be fixed already on the latest edge
@SpookyUSAF commented on GitHub (Sep 7, 2025):
I really want to like and use Actual Budget and support the project, but the slowness of it has become unbearable and approaching unusable. The idea of having to reset the SyncID hours after installing and using the application/server seems like something that shouldn't be necessary and is a big red flag for the stability of this project.
Anyway... Synolog DS920+ w/ 16GB RAM, no performance issues spikes during AB usage, system is basically idle even when AB is slow in Win 11 APP and Edge (latest version). No network spikes. No CPU spikes shown in resource monitor, however I do hear my system fan speed up occasionally while completing a reconcile, adding a schedule, or accepting a scheduled transaction.
Win app takes about 1-2 minutes to be useable able startup, 20-30 second pauses to switch accounts... using Edge was a lot faster however last night I added about 30 scheduled transactions this morning it's incredibly slow.
I should add that performance on the iPhone Edge browser is still good, with the exception that the account transactions are displayed very quickly, but it takes 30-60 seconds for the scheduled transactions to appear at the top and schedule icons to display.
@SpookyUSAF commented on GitHub (Sep 7, 2025):
As a sidenote... I am determined to make this work! I performed the sync reset finally and noted that my budget files on the server changed as follows:
Before reset:
group-xxx.sqlite was 2.2 MB
file-xxx.blob was 7.0 MB
After reset:
group-xxx.sqlite is16 KB (Now 68 KB after a bunch of work done)
file-xxx.blob is 6.2 MB (Doesn't appear to change with usage)
Performance of both the web apps and Windows 11 app is identical and good.
@SpookyUSAF commented on GitHub (Sep 8, 2025):
One more comment on this... Since the sqlite database file contains all the changes to the blob file and can apparently become extremely huge, is there any plan or existing schedule to merge the changes to the blob file at a certain size limit and then just invisibly (without prompt) force "revert" all the clients that sync this budget? This would potentially solve the apparent performance issues related to large change files.
@youngcw commented on GitHub (Sep 8, 2025):
I think it's on a timer in the server. I don't know for certain so you would have to check. I want to say 2 weeks
@SpookyUSAF commented on GitHub (Sep 9, 2025):
Today I made a bunch of updates to a few off-budget investment accounts. The sqllite file on the server is now 308kb and performance in the pits now. Trying to reconcile one of those investment accounts resulted in about a one minute freeze on every click, in both Edge and the Windows 11 app. I've been monitoring resource monitor disk and CPU usage and don't see anything that causes alarm.
@SpookyUSAF commented on GitHub (Sep 24, 2025):
To update this, I've been travelling and using Actual exclusively but it's unbearable and I might have to bail back to YNAB.
Using Actual on my iPhone is as slow as using it anywhere else. I updated from a iPhone 14 Pro Max to a Galaxy S25 Ultra last week and Actual has the same long delays in the Edge web browser. I thought maybe having one of the fastest processors would help. Reconciling a statement? Forget it! It takes almost 30 seconds for Actual to show the balance after clicking the lock. It then takes ~ ten seconds from the time I click a transaction to the time it shows up checked.
On mobile, both phones, I'll enter the amount, tap into the payee and the amount goes blank. I'll finish the payee, tap back into the amount and the payee disappears. If my server were very slow (it isn't) I would expect this. However Actual claims to be running with all data on the local machine and only syncing in the background. Why would it be this slow if all the data is actually local?
@Kidglove57 commented on GitHub (Sep 24, 2025):
This is for the record only. I am running Actual on iOS (iPhone 15 Pro Max) in Safari. It is extremely fast despite having 5 years of transactions and 60 accounts.
Might this issue be browser specific?
Edit: nope - just downloaded Edge browser on my iPhone and fired up my Actual document (hosted on Fly.io) - it’s lightening fast.
@matt-fidd commented on GitHub (Sep 24, 2025):
I'd love to help debug this, but I can not reproduce it on my side. Are you able to reproduce it on https://edge.actualbudget.com?
If so, would you be able to send me a budget file that can reproduce it over Discord?
@SpookyUSAF commented on GitHub (Sep 24, 2025):
If I use edge.actualbudget.com with a local file only no data is sent right? I've got 10 years of data here in a 7mb file so recreating it will not be possible.
Also, what happens when you mark a transaction as cleared or uncleared? Is there anything happening on the server or is it all local? Even on my phone, marking a single transaction as cleared takes 5+ seconds, and marking it uncleared right after takes about 20 seconds before the flyover shows up, then another 10 seconds before the green check changes back to gray. Curious to know what's happening during those long delays.
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Matt Fiddaman @.>
Sent: Wednesday, September 24, 2025 7:42:02 AM
To: actualbudget/actual @.>
Cc: SpookyUSAF @.>; Comment @.>
Subject: Re: [actualbudget/actual] [Bug]: Performance - adding / removing budget items very slow (Issue #4045)
[https://avatars.githubusercontent.com/u/81489167?s=20&v=4]matt-fidd left a comment (actualbudget/actual#4045)https://github.com/actualbudget/actual/issues/4045#issuecomment-3327998518
To update this, I've been travelling and using Actual exclusively but it's unbearable and I might have to bail back to YNAB.
Using Actual on my iPhone is as slow as using it anywhere else. I updated from a iPhone 14 Pro Max to a Galaxy S25 Ultra last week and Actual has the same long delays in the Edge web browser. I thought maybe having one of the fastest processors would help. Reconciling a statement? Forget it! It takes almost 30 seconds for Actual to show the balance after clicking the lock. It then takes ~ ten seconds from the time I click a transaction to the time it shows up checked.
On mobile, both phones, I'll enter the amount, tap into the payee and the amount goes blank. I'll finish the payee, tap back into the amount and the payee disappears. If my server were very slow (it isn't) I would expect this. However Actual claims to be running with all data on the local machine and only syncing in the background. Why would it be this slow if all the data is actually local?
I'd love to help debug this, but I can not reproduce it on my side. Are you able to reproduce it on https://edge.actualbudget.comhttps://edge.actualbudget.com/?
If so, would you be able to send me a budget file that can reproduce it over Discord?
—
Reply to this email directly, view it on GitHubhttps://github.com/actualbudget/actual/issues/4045#issuecomment-3327998518, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJTLTVNWAGHSZ4MENGT4AHT3UJ7QVAVCNFSM6AAAAABUHOMWWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRXHE4TQNJRHA.
You are receiving this because you commented.Message ID: @.***>
@matt-fidd commented on GitHub (Sep 24, 2025):
Correct, it'll all stay on your device.
When it's marked as cleared, it's updated in the DB, I imagine some balances are recalculated and then it's synced back up to the server. You should not be seeing these sorts of delays from such a small operation, there's got to be something else at play.
@SpookyUSAF commented on GitHub (Sep 24, 2025):
Okay, I used edge.actualbudget.com and connected my server and data file. I thought it was going to be fast because it loaded balances instantly and switching between accounts was fast. Then I marked three transactions as cleared and they didn't do the usual "turns back to gray, then 5-20 seconds later turns back to green" cycles. However, a few seconds after I marked them as cleared I switched to another account, and it acted like it was frozen. Then about a minute later everything updated and the cycle repeated.
The current state of my data file is that it was imported from nYNAB, ran the fixes, updated a few transactions that needed tweaking to get balances to line up thanks to nYNAB's dumb loan account, and then merged/deleted a lot of payee's to clean it up. When I first observed the slowness, I used common advice to reset the sync and it did speed it up significantly back then.
After seeing the slowness still while using edge.actualbudget.com, I decided to just reset sync again. It did not help this time. Just switching between accounts is taking a long time, on both the mobile device, PC via browser and PC via Actual App.
@matt-fidd commented on GitHub (Sep 24, 2025):
Okay, thanks. I can only think that it must be some weird data causing the app to get stuck somewhere. I've never seen slowdowns like you're describing, even with huge files.
Without being able to see your file, there's probably only so much I can do. My last suggestion is for you to use the profiler tool built into Chrome to have a look at the call stack and see where the slowdown is. https://www.codemancers.com/blog/2023-08-18-chrome-profiler should help you if you don't know where to find it.
@SpookyUSAF commented on GitHub (Sep 24, 2025):
The tracing tool is being a real pain in the rear. I've done three ~75 second traces showing clearing five transactions and then unclearing them. Every time I try to save the trace (with screenshots), the dev window just disappears. At least it's consistent.
@matt-fidd commented on GitHub (Sep 24, 2025):
That's annoying, but without that or your budget file, the scope to investigate this is very small.
It's worth checking it really is disappearing, not just hiding behind your browser window, that's caught me out a few times. It's often easier to pop it out into its own window to do this sort of thing.
@SpookyUSAF commented on GitHub (Sep 24, 2025):
Unfortunately I had to get to work. I will attempt this again tonight because you can clearly see in the trace and screenshot where I click the 3 transactions, the green checks appear but disappear after a few seconds and then over the course of a minute the green bubbles slowly appear again. I hope this will give you what you need. How do I share the file with you privately?
Get Outlook for Androidhttps://aka.ms/AAb9ysg
From: Matt Fiddaman @.>
Sent: Wednesday, September 24, 2025 11:20:12 AM
To: actualbudget/actual @.>
Cc: SpookyUSAF @.>; Comment @.>
Subject: Re: [actualbudget/actual] [Bug]: Performance - adding / removing budget items very slow (Issue #4045)
[https://avatars.githubusercontent.com/u/81489167?s=20&v=4]matt-fidd left a comment (actualbudget/actual#4045)https://github.com/actualbudget/actual/issues/4045#issuecomment-3329314777
The tracing tool is being a real pain in the rear. I've done three ~75 second traces showing clearing five transactions and then unclearing them. Every time I try to save the trace (with screenshots), the dev window just disappears. At least it's consistent.
That's annoying, but without that or your budget file, the scope to investigate this is very small.
It's worth checking it really is disappearing, not just hiding behind your browser window, that's caught me out a few times. It's often easier to pop it out into its own window to do this sort of thing.
—
Reply to this email directly, view it on GitHubhttps://github.com/actualbudget/actual/issues/4045#issuecomment-3329314777, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJTLTVJR7TW62IAKTSNIMS33UKZCZAVCNFSM6AAAAABUHOMWWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRZGMYTINZXG4.
You are receiving this because you commented.Message ID: @.***>
@matt-fidd commented on GitHub (Sep 24, 2025):
No problem, hopefully it works better later on!
Discord is the easiest way, you can find me through the Maintainer list on the server, @mattfidd.