-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve folder enumeration speed #4199
Conversation
@gave92 I'll test the changes. |
Thanks @yaichenbaum I'm curious to know if it's just my mind playing tricks xD |
@gave92 I wouldn't say it's as fast as File Explorer, but it does seem to be faster than before. |
@yaichenbaum thanks, I feared the "maybe a bit faster" answer, probably going to close this xD Edit: did you have any caching feature turned on before testing this PR? |
@gave92 I thought this PR removes the cache option. Either way, it's a nice improvement and I think it's worth it to continue. |
@yaichenbaum Yep, funniest thing is that removing the caching feature makes things faster :) I'm going to leave this open to gather more feedback. If confirmed it would be a nice simplification of the code. |
@gave92 It definitely makes things faster, and I can see items mush faster than before. |
@jakoss Can you test these changes? |
@xpoppyx could you try again with the latest "Small fixes" commit? |
@xpoppyx thanks, I'll be interested in knowing how's loading speed for you (small/large/network folders) with this PR. |
For #4180 |
@xpoppyx I would not expect the issue to be tied to this PR, is this something that does not happen on main? Could you post the |
Since this PR effectively disables the cache, I'm convinced the issue exists on main as well. |
It does seems to make the loading faster, the question here is at what point the cache became the choking point? Because all cache-related code shouldn't make that of a difference, even the database operations were at 50ms tops |
@yaichenbaum good for me. I'm gonna keep this to separate the other changes I ended up putting in here. |
This reverts commit 7f4b83e.
@gave92 It looks like scrolling is a little choppy when items are still loading. It also looks like it doesn't always work to change the layout mode. Overall, though, there seems to be a massive increase in performance. Do you think we should remove the cache setting and make it the default? |
Perceived increase, thing is currently for folders with less than 32 elements, it wastes time loading from the cache but never adds the items to the UI. With this PR cached items are shown also for small folders (plus there are a couple of tweaks that should actually reduce the loading time)
Yup, it shows cached items immediately but then it's busy loading the actual folder. Before you didn't notice because items appeared when it was done loading.
Could you clarify this?
Side note: Rx-Explorer has even faster loading performance and uses no cache whatsoever. |
Clicking on the different layout options in the display flyout don't always switch the layout mode.
Is it faster than all the layout modes, or just the one with the DataGrid? |
@yaichenbaum mostly tried in details view only (they use a ListView underneath I think, not DataGrid which may explain some of the difference?) |
That's why I asked, I figured the DataGrid might be part of the slowness. Regarding the cache, if we can improve the speed, we can definitely remove the cache altogether. |
I noticed this PR significantly decreases the loading speed of shortcuts (I'm assuming because now they have to be obtained through the FTP every time). This may not be feasible, but perhaps just shortcuts could be cached since they take a lot longer to load than other items? |
@winston-de at the end we did not remove the caching feature so it shouldn't take longer to load folder contents. Do you find that a folder with a lot of shortcuts now loads slower? |
@gave92 It looks like the json deserializer was breaking when trying to deserialize shortcut items, which slowed down the loading speed. Oddly enough, it seems to have stopped, and the loading speed is just as fast as other folders. Here was the error that was causing it:
However, this is not an issue with this pr, as my log shows the same error going back to at least February. I'll file a new issue for this. |
#4283 is supposed to have fixed that issue (adds empty constructor for shortcut listed item) |
Hmmmm I'm still getting the error. I'll try clearing the cache, maybe that'll fix it. |
Resolved / Related Issues
Fixes #4028
Details of Changes
This PR:
Removes the caching feature which appears to slow down loading for small, local folders-> restored