Re: Floating point in pango
- From: Soeren Sandmann <sandmann daimi au dk>
- To: Richard Purdie <richard openedhand com>
- Cc: Behdad Esfahbod <behdad behdad org>, performance-list gnome org
- Subject: Re: Floating point in pango
- Date: 14 Jul 2006 19:25:46 +0200
Richard Purdie <richard openedhand com> writes:
> Technically, oprofile can do everything sysprof can and a lot more
> besides (plus it already works on ARM). oprofile as a profiler is
> therefore the better piece of software. sysprof has a pretty GUI though
> which seems to attract people more than the capabilities.
Err, no oprofile can't do everything sysprof can. Not even close.
The _kernel_ part of oprofile has tons and tons of useless features
that the sysprof module doesn't have, but as a whole sysprof is a lot
more useful than oprofile, at least for profiling desktop
applications.
> The real task is for someone to write a nice GUI for viewing oprofile
> traces. The problem is that sysprof's UI can't handle all the added data
> oprofile can provide and oprofile's power is a disadvantage when people
> have tried to design a good GUI for it.
You are assuming here that writing a profiler amounts to
1. Write singing and dancing kernel feature with enough
features that everything that could conceivably be
measured, can be measured. (50% of the development time).
2. Write singing and dancing user space collector with daemons
and command line tools, that will save profiling data in
secret places on the disk. (49% of the development time).
2. Write pretty GUI frontend for the command line tools that
the n00bs can use. (1% of the development time).
which is _retarded_ and guaranteed to produce something that nobody
would actually _want_ to use. And the reason is that it doesn't focus
on solving a real problem, it focuses on making use of particular
hardware features.
What I did with sysprof was to start from the question
"What would it take to get GNOME people to do useful profiling
of their applications?"
which _was_ a real problem. And the answer was along the lines of
- GNOME people spend most of their time _writing_ software.
_Profiling_ software is a relatively small part of their time. They
are not going to go through some complicated setup every time they
need to profile something. This is a big part of the reason sysprof
data collection and analysis are in one application.
- GNOME applications tend to be broken down into many functions that
call eachother deeply. They are often recursive. And some of the
biggest performance problems (at the time) were algorithmic in
nature. These things implied that call graph visualization was
essential. Oprofile _does not have this feature_. And no, it's not
just a question of writing a "pretty GUI". Getting features like
this one right is the _hard_ part of writing a profiler.
- GNOME is heavily using the X server, so a profiler that only
profiled individual applications would give misleading data. So
there had to be kernel support, but the amount of kernel support
needed was small and it would have taken me longer to dig through
the oprofile source, than to just write the less than 300 line
module I needed.
- Often the person who has the performance problem is not the one who
can fix it, so it has to be possible to communicate profile data
between people. Oprofile does not have this feature; the only thing
you can communicate is particular ways of viewing the data.
So that determined the basic design. Another concern was that I am not
rockstar enough to convince people to _use_ it; the best I can hope
for is to convince people to _try_ it. So there had to be a high
likelyhood of success when people use sysprof for the first time, so
that they will continue to use it.
And then there is basic usability stuff, such as having a simple
conceptual model and requiring only few clicks to use it. The oprofile
GUI is really funny in this regard if you have a morbid sense of
humor.
These things together led to sysprof being the way it is. Most of the
oprofile features are _useless_ given the design criteria above, and
most of the features _actually_ needed are just not there in oprofile.
Soren
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]