Skip to content
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

nemo 4.6 much slower than 4.4 #2530

Open
howdev opened this issue Oct 9, 2020 · 14 comments
Open

nemo 4.6 much slower than 4.4 #2530

howdev opened this issue Oct 9, 2020 · 14 comments

Comments

@howdev
Copy link

howdev commented Oct 9, 2020

 * Nemo version (nemo 4.6)
 *  issue with windowed nemo
 * Distribution Mint 20
 * Nvidia 450.66
 * 64 bit

Issue
Nemo browsing performance is much slower than 4.4, it were as if running Nemo 3.x
There is a delay opening any folder size

Steps to reproduce
install nemo 4.6 or use Mint 20
run nemo, browse folders

Expected behaviour
fast on opening folders

Other information

@icarter09
Copy link
Member

@howdev how long of a delay are you experiencing?

@howdev
Copy link
Author

howdev commented Nov 11, 2020

@icarter09 populating the folders is same long delay as nemo 3.x. while nemo 4.4 is as fast as thunar.

@Jeremy7701
Copy link
Contributor

Could you quantify that?
How many seconds to populate a directory which has X files in it?

@howdev
Copy link
Author

howdev commented Nov 11, 2020

@Jeremy7701 how do you measure? with what tool?

@Jeremy7701
Copy link
Contributor

I'd say a sub-second response is fast.
If the thumbnail is not in the cache, then the asynchronous thumb-nailing process can be quite slow, depending on the type of file. Videos are especially slow.
From the CLI,
time nemo 'full_path_to_some_folder' always gives (with slight variation),

real	0m0.092s
user	0m0.071s
sys	0m0.016s

In the icon view, all files are displayed in their correct positions, as a rectangular array [but not necessarily with the icons filled in].
Building non-cached custom icon images can take a number of seconds, though; I don't know how you would measure that.

I arrange for thumbnails to remain in the cache for about two weeks - for me it seems to strike a balance between cache size and generating fresh entries in nemo.

@howdev
Copy link
Author

howdev commented Nov 12, 2020

@Jeremy7701 cannot use time command for this because it does not show the time it takes for folder to appear. it only time it takes for nemo to startup. The folder appears after the time results already shown in the console.

you can time folder display only by adding timer in the source code.
The issue is there is a delay in showing folders, meaning blank view, then folders appears, is like a blink, but a slow blink. In version 4.4 you can't see blink, is just instant

@howdev
Copy link
Author

howdev commented Nov 12, 2020

@Jeremy7701 can attach video here in github?

@howdev
Copy link
Author

howdev commented Nov 12, 2020

nemo-4.4-vs-4.6.zip

here is two videos showing 4.4 being much faster than 4.6 on /usr/bin directory as an example

@Jeremy7701
Copy link
Contributor

I can definitely confirm the speed (or lack of it) as on the 4.6 video.
I don't have access to 4.4.

/usr/bin (2,500+ files) is very slow - the first time - perhaps 10+ seconds.
If I restart nemo and try a second time it fills with no noticeable delay.
I would say this was due to caching, except that virtually all the files have some kind of default icon.

@howdev
Copy link
Author

howdev commented Nov 12, 2020

@Jeremy7701 In my video demonstration, is not caching, as I reloaded twice and 4.6 is still slow no matter how many times you open the same folder. You can press F5 refresh and 4.6 is still slow

It appears though in 4.4 it is showing the files and folder straight away at same time as it is getting the data from the directory, you can see the iconview updating, unlike 4.6 waited for all data then display.

@Jeremy7701
Copy link
Contributor

A reboot causes 4.6 to revert to its slow behaviour on /usr/bin.
4.6 shows an 'in progress' indicator whilst it is generating the custom icons.
A F5 refresh remains very fast.
/usr/bin is my only large folder consisting entirely of files.
/usr/share/doc [2,801 items] has all entries as sub-folders and it loads very quickly.

I'm happy to accept that folders containing thousands of files are going to suffer a speed penalty, especially since such folders can become difficult to manage.

@howdev
Copy link
Author

howdev commented Nov 13, 2020

even low items folders, 4.4 is faster. 4.6 is lagging. So generally when you traverse through directories, the experience is very slow with 4.6, you have to wait till items appear before you can click on them.

@deutrino
Copy link

I am seeing poor performance in folders with dozens to hundreds of image files.

Thumbnailing seems to be only part of the problem - for example, if I allow the images to be thumbnailed, then open a subfolder, then go back up to the first folder, performance is still noticeably laggy.

@jondo
Copy link

jondo commented Jun 2, 2022

Remark: #1907 and #2291 were previous slowness issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants