The openSUSE GNOME Team spent last week hunting bugs in the GNOME Main Menu. Since I was on site at a customer, I entirely missed the event
So I thought I should try to make up for it, by profiling g-m-m today.
The first thing I found was this;
Adding Favorite Documents and Recently Used Documents to m-m accounts for >20% of it’s startup time. Out of that, 19% is spent in gnome_vfs_mime_get_default_application.
Looking at the code for it reveals (surprise surprise) that it’s used to figure out what default application to open the document with. It seemed unnecessary to call such an expensive function for each Document so I decided to move it out of there. That meant that for each application, document_tile_private_setup would now use a standard function (run a function which in turn opens nautilus) instead. That standard function will only be called if the user clicks on a Document, so I added the call to gnome_vfs_mime_get_default_application in there. This will not only save valuable startup time, but also a little bit of memory.
The next thing I looked at, and it is one of my favorite things to do in Slab, is the creation of a context menu for each Document. Again, the only time it would be used, is if the user right clicks on a Document. So I modified the code to only create the context menu if the user right-clicks on a document. Again, some savings in both startup time and memory.
Then the third thing, and which took most of the time today, was the fix up the following;
The create_rct_docs_section accounts for 45% of the initialization here. All up, tile_table_new, which is called by each function that adds an item to m-m, is using 57%.
After moving the code around a bit (sounds easy doesn’t it?), and also fixed a bug, I ended up with this;
Now, that looks alright for a days work. Although not all finished with this yet (need to fix a bug that I introduced :-), it was a good day overall.
I tried to publish the diff here but wordpress didn’t like it much. Download it from here instead.
I just realized that it looks a bit funny when comparing the two charts above. To clarify, it does not mean that the startup time have been reduced by >50%. These are numbers from the current view that I was looking at. Some of the work is now done in other functions which is not visible in the last chart. Once done with this first round of optimizations, I’ll try to publish a better view which shows how much we’ve gained.