Re: Floating point in pango

[Richard Purdie <richard openedhand com>]

On Fri, 2006-07-14 at 19:25 +0200, Soeren Sandmann wrote:
> 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.

What I said originally, still stands and you reinforce it here. From the
technical standpoint, the kernel side of oprofile is better. It caters
for performance monitoring hardware and those features are not exactly
"useless" but improve the accuracy and resolution of the traces as well
as reducing impact on the systems being traced.

> > 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).

This is the point of a good kernel interface. It gives you control over
all the features of the hardware. Kernel interfaces do not follow GNOME
design guidelines but aim to give userspace all the options.

>         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).

Without this separation, you can't take traces on one architecture and
analyse them on another. On a handheld where you don't want to run the
GUI application on the device as it might not even be capable of that.

>         2. Write pretty GUI frontend for the command line tools that
>            the n00bs can use. (1% of the development time).

So sysprof ignored the first two and spent time on the latter only? At
best that makes you as bad as each other. In reality, you can build a
nice GUI onto oprofile, sysprof has no foundations to build upon.

> 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

That is a great question to start the GUI from and its where I'd like to
see someone start oprofiles GUI.

> - 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.

Have the GUI hide the backend by all means, thats its job. It does not
mean it has to be one application. See above for cases where you might
want or *need* separation.

> - 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.

oprofile has call graph support and provides perfectly readable text
graphs so I can't see what you're getting at?

> - 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.

So you're lazy and like to duplicate code? I can't see what else you
mean :-(.

> - 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.

That is total fabrication. If anything oprofile handles this better than
sysprof as oprofile supports many more architectures and allows transfer
of traces between them.

> 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.

oprofile doesn't have a good GUI. In fact I don't consider it to have a
GUI at all and the oprofile authors would agree.

> 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.

So basically sysprof concentrated on the frontend and I agree it did
well with it. It just lacks the backend and infrastructure.

oprofile lacks a GUI and my original email said as much but it does have
a solid infrastructure behind it.

There is a logical conclusion here, change sysprof to be a graphical
frontend to oprofile. 

FWIW, I'm impressed with the sysprof frontend. I'm equally impressed
with the oprofile backend. I wish the two camps would stop fighting and
try and work together and create something even better than what
currently exists.

Regards,

Richard

-- 
Richard Purdie
Openedhand Ltd.