[Bug]: Performance - adding / removing budget items very slow

[quarklark]

Verified issue does not already exist?

• I have searched and found no existing issue

What happened?

With a larger files, the application becomes very slow to load at various points.
Specific points I've seen are:

1. Opening the file (load screen)
2. Adding a budget category
3. Removing a budget category

How can we reproduce the issue?

1. Create a new file.
2. Add a significant number of accounts & transactions. (> 10 accounts, with > 200 records each.)
3. Add a new category to the budget

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]

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.

Screen.Recording.2024-12-26.at.11.55.27.AM.mov

[youngcw]

Try resetting the budget cache

[quarklark]

Trying this now - any idea how long it should take? So far it's been about 30min & it's still spinning?

[quarklark]

1hour in, still working. I restarted the app, which loaded like normal (~15 seconds on load screen). Still having the same issue.

[youngcw]

Hmm. Something must be off. If you are using a server try redownloading. If not try exporting and reimporting.

[quarklark]

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]

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]

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]

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]

Ok - ruling out platform. I'm seeing the same issue on a new PikaPods instance after importing my file.

[youngcw]

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]

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]

Somewhat related issue.
I'm using actualpy to import ~22k transactions to the server running inside a docker container. Commit stage clocks at 3h45m and counting.

[youngcw]

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.

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]

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]

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.

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]

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]

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.

Have you reset the sync id? That usually speeds things up if you just did an import

[johnnysbug]

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]

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.0

I'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]

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.