GNOME Bugzilla – Bug 124524
Nautilus too slow (20 secs) to startup on solaris(PATCH)
Last modified: 2005-08-15 01:57:44 UTC
I built gnome 2.4 on solaris 2.6 and I find nautilus very slow on solaris, whereas the same build parameters on linux don't make it so slow. It takes around 20 secs to startup on solaris while it takes around 2 secs on my linux machine. I did a truss on the nautilus and found that it was "stat"ing my /net and /vobs shares all the while(every 2 seconds, which I consider too little a timeout). On our company intranet, automount mounts tonnes of networked systems in /net and /vobs, and 'stat'ing those doesn't make any sense during startup. It should be done on demand or later on in the bg. Why does it stat and load all the configuration files, .xml, .png, .svg, mime-info, /usr/share directories etc. when I open a new window. When no window is open, the process is still there in the memory(eating 37MB), why does it stat and load the conf again? It stats, opens and reads every single file in my home dir(including all .* files), is it trying to get their sizes this way? Why? I want to understand this. Somebody please explain. Then there are miles long of time() calls. Is that a wierd way of passing a specified amount of time? Another thing I notice is that existing windows also blank out till the new window comes up when I open a new window. This happens for all the new opened windows. I am not sure what else does it do during startup that makes it so slow. But I have a request for nautilus developers: please look into making this thing fast for 2.6 instead of going for new features.
On linux, it doesn't open and read all files in my home dir. Why on solaris?
Could it be related to famd being suboptimally implemented on solaris? not being there at all? difference in hardware performance? It's hard to say without more details.
could be because of absence of famd! But why should it try to read all files in home dir during startup? stat, open, read and then lseek on all files in home dir! which function is doing that, any idea? I can confirm this because the other user's home on the system is slightly less cluttered than me and he loads nautilus faster but only few seconds. Then there is this call to time(). For 3-4 seconds, in the truss output I don't see anything but time(). I can see the return value getting incremented after few tens of calls. And this is the time when nautilus window is totally un-responsive(100% cpu usage). Only thing I could find was gnome-vfs(get_value_real) doing time() to see if its time to reload mime-data. It does check for 5 seconds elapse time. This is like "are we there yet". why not have a glib timeout based callback for this as well? Would you know of any other function doing time() in a loop like that unintentionally?
it feels like hang because during those 3-4 seconds of looping time() calls, it doesn't do poll() for input events, otherwise I would see those system calls.
Created attachment 20731 [details] relevant truss output
first and last four lines: processing input events. in between (10 secs have passed and its frozen during that time), don't know what its trying to do but its reading heck a load of icons and seems to be searching in hard coded places like /usr/share/pixmaps. On solaris, I have installed gnome under my home. simple theme with gnome default icons, same result.
Created attachment 20741 [details] [review] Update nautilus-scripts directory based menu using g_timeout
hahaha...some guys like to abuse nautilus-scripts. I am one of them. I have like 10 dirs in there, each one has 3 dirs and each of those has like 8 files each. When nautilus goes to update menus, it tries to load all of these(around 250 files) at once, getting mime-info, doing icon-lookups(continuous time() calls from these two) etc. Someone (I mean developer) decided they will do breadth first search of the FS tree and every time they will go one level deep, building list of dirs to process in one shot at the deepest level. Well, it takes 10 secs to accomplish that last step in one whole for my 30 dirs. During that time nautilus GUI doesn't respond. When I open a nautilus window, it is usually to search for a file and open it with one of the default programs. So, I need quick response. Menus can update slowly, over a period of 30 secs or even a minute. I don't care. So, I added this quick fix hack to schedule each of the dirs to update one after the other every one second using g_timeout_add. So, GUI stays free and available. The patch is a great relief on CPU usage and GUI responsiveness!! definitely try, but on your own risk...;) please let me know of any bug you see in there, since I am new to the g-coding. If you are leaving nautilus-scripts to the users and file system limits, your update algorithm should be smarter than what it is now. Gurus, please take over! PS: BTW, linux nautilus cried too, when I copied the same scripts over to my linux box.
Re-opening, setting priority->high and adding PATCH keyword.
there is a obvious bug here. if you close the window before the timers expire, the g timers are not cleared and hence can lead to segv. I will have a more sober patch ready soon.
Created attachment 20755 [details] [review] A stable working patch.
I finally got the time to write it. Have a look and let me know.
Created attachment 20763 [details] [review] why copy list?
Upgrading priority to High due to the attached patches.
you should send your patch nautilus-list@gnome.org so that it gets some developer attention.
Adding the portability keyword.
Also adding the perf keyword, and cc'ing wipro in case they are interested.
Created attachment 29292 [details] truss on nautilus when it hangs for 3 seconds or more This truss output shows that nautilus is not doing anything but polling for X events on socket 4, time() return value keeps increasing and the CPU usage is 100% for nautilus during these 3 seconds. Will someone who knows enough about nautilus be kind enough to explain why it happens? This happens when I click on the "File" menu item on a nautilus window.
Do you still see these performance problems?
Sunil, any news?
please close this bug. I have no interest in nautilus anymore.
OK. Thank you anyway. Let's hope the new features in Nautilus 2.12 will convince you to spend some time on it again.