Once again it's been forever since I updated my diary. I think I should let people know what's been going on.
I've been spending time in the last few days getting familiar with performance tools that are out there for Linux. One of the problems that we face in the Mozilla project is that the developer tools on Linux aren't as good as what's available on Windows or on Solaris*. Spending an hour with Quanity or Purify can make a huge difference in knowing why your product or project might be slow.
Some people say that if your product is slow then you've designed it incorrectly or you don't really know what's going on. That's true to a certain degree, sure. But when you've got 80+ developers working on a project and not any of them can understand or be familiar with the subtle interactions of different components it's very important to have the tools that might tell you what's wrong with what you're doing. That's where those performance tools step in.
We have a scattering of performance tools for Linux but not anything that really compares with developer tools on other platforms. There's gprof but gprof doesn't work with shared libraries. For shared libraries there's sprof but it only works on a single library at a time and appears to have issues in Mozilla. ( Those problems could be thread related - not really sure. ) Given that Mozilla is built of a couple dozen shared libraries, uses threads extensively, and is a huge chunk of code the options that are out there aren't really fitting the bill.
After looking at the code that's currently in libc ( the gmon/mcount code ) it looks like it can be pretty easily extended to handle shared libraries. The only problem with that is that you have to change the output format to support more than one shared object at a time. This means that you also have to change the programs that process that output since none of them handle more than one shared object at a time either so it means either implementing something new or adding support to gprof to handle it. The latter is probably easier so that's where I'm going to go first.
I've already got code that does lookups from the profiling code to find the right library it was executed from. Looking in the internals of the dynamic linker is something that I've never done before so the learning curve has been large but I've found that it's all very interesting stuff. I get to learn all about elf, dyanmic loaders, compilers, linkers, etc. I've never had any reason to do that in the past and it's a breath of fresh air to learn something completely new and feel completely invigorated doing it.
In other news ramiro has checked in the code that implements the bonobo component for nautilus. I'll play with that tomorrow, in addition to working on the embedding widget. The widget really needs to inherit from the GtkMozBox, not GtkWidget. It also needs signals for loading progress and finishing loading. I have to fix a couple of DND bugs so that you can drag from the desktop onto Mozilla, too.
There are a lot of people who are trying to get that component working with the M15 release of Mozilla. Don't. It doesn't work. You'll just get a crash and then send me email. Then I'll send you email saying "I know it doesn't work. Please update to the tip. I'm sorry."
Also in the last couple of days menus and mail/news in Mozilla have gotten a lot faster. I'm using Mozilla for email about half the time now. It still formats outgoing email poorly and some of the fonts look really strange but it's pretty functional.
I promise I'll try to update this more often. :)
* But hey, at least we're not the Mac.