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.