Re: Gnome 2.14 Module Proposal: Deskbar Applet

Hi !

I'll try to reply to  some things that have been discussed on this
thread recently

> > So assuming there has been no action on this front I guess
> > there are three ways to fix this:
> > 
> >  * Fix the Python interpreter to use a real compacting GC
> That could be worse! Compacting GC's require twice the memory of a 
> non-compacting one. (you dont know how much garbage you have when you 
> walk the heap to GC so you need another empty heap of the same size to 
> copy everything into it)

As i understand the paper that was linked to, on python memory
management, the peak memory used by a program will be the maximum memory
it will ever use, i don't think deskbar has large bursts of memory
requirements, and as such won't have an ever expanding memory
consumption which could lead to problems.

So Yes, it will eat your memory, but not increasingly with time

> > 
> >  * Rewrite the applet in something other than Python and which
> >    isn't going to cause massive flamewars (which basically means
> >    C or C++)
> Could do but might not be economical time wise for the devloper(s)
> I love how gnome-launch-box works (more then an applet for this type
> of things), but it lacks many of the functionality deskbar backend
> has got...

Guess why ?

Let's be clear here, developing with python is fun, and quick, it's a
prototyping language. Writing the same program in C would require much
more time, bug fixing, memleak-fixing, and other things few want to do.
Python has easy way to add independnt modules, with C it's a pain in the

We won't switch to C or C++ anytime soon. It can be considered once the
codebase is stable and the features well settled down, but certainly not
in the 2.14 timeframe.

> We (Christian Meyer, Martin Grimme and I) worked a lot on gdesklets to
> reduce its memory usage, and iirc, We never got significant results.
> May be we once managed to get 1MB back. Fixing memory leak in python
> gdk helped a lot, but that was not our code. 

I think the point is clear, python eats your memory, live with it.

> Or:
>  * Rewrite performance-sensitive parts of the deskbar applet in C,
>    but keep the rest in python.
> That technique works well for CPU-speed limited code, but would
> probably make little difference for memory usage unless nearly all was
> written in C. Bear in mind the interpreter itself carries quite a
> large fixed overhead. But I guess you'd need to do some memory
> profiling (assuming there are tools that can profile the python
> heaps).

There are no CPU-intensive parts in deskbar except startup because we
crate an index, so there is no point in implementing some parts in C and
others no, it's either all or nothing.

> If start-up of deskbar blocks the panel, then it is an issue :-) Else,
> it might not be an issue for the user.

Deskbar does not block the panel while loading, it just does a lot of IO
to index the files it needs, the only blocking thing is deskbar itself
(and it's greyed out during that time).

> > Start-up time may not be that big an issue if it's a one-off and
> doesn't stop you otherwise using your desktop.  This may be a bigger
> concern for those who want to replace the Alt-F2 Run dialog.

In the current state of things, having it as quick-start standalone
alt-f2 dialog is not possible, since it takes relatively long to start.
Now if we don't take startup time, it is easy to have it quickly start
if there is an instance running somewhere before.

> i meant 6s startup with CPU 100%

Yes that's a problem and we will be fixing it, but if you install the
applet you are accepting it's drawbacks.

> I really don't see what's the point in getting python into desktop.
> Many people are spending their time optimizing startup time and memory
> usage.
> A single python applet would annihilate all that painful work. I'am a
> python hacker but i think it is unaffortable in desktop.

Having the desktop or email program (*hint* /me looks at evolution
*hint*) start fast is crucial.

Having an applet start slow is just a problem for those who care about
performance. That excludes lots of users, me being the first. That and
the fact that an applet is something you choose to use, whereas you
*have* to use evolution on a stock gnome desktop.

So to summarize the discussion:
* Yes, deskbar is written in python and that won't be changing soon, and
not in 2.14 timeframe.

* The startup time and CPU usage is problematic but there is not much to
be done (more below)

* We propose deskbar to become an applet, nothing more, nothing less,
applets are optionally used by users, and by using them users are
accepting the consequences. If we see the functions provided by it are
useful to replace mini-commander/alt-f2 let's discuss how to do it
properly, instead of bashing python, if doing it without python is not
an option, let's not consider that use-case.

* Most users don't care about an applet taking a bit more memory than
others, most will not even see it.

* Deskbar doesn't block the gnome panel

Concerning the startup time (i do not have any figures to back this up,
just my intuition) (also most of the time deskbar will be launched when
the caches are 'cold'):
* 1 second to launch python/bonobo
* 1 second to init pygtk
* 1 second to init misc lib stuff
* 3 seconds to index
 - .desktop files (also lot of IO here)
 - browser bookmarks, search engines
 - browser history

The first three points can hardly be trimmed down.

The last point is the core of deskbar, remove that and you have

The other features are provided by 'live' handlers, that means they
generate their answers on the fly, for example by querying gconf, or
seeing if a given name matches an executable, or querying
beagle/evolution-data-server. These operations are nearly instantaneous
and happen only when typing something.

As i see it, the browser problem could be resolved by having some kind
of epiphany-data-server, or other dbus mechanisms able to deliver
instant answers. However:
* the mechanism should not require epiphany to be running
* People don't like daemons (people are lame :))
* It just makes mozilla out of the play (I use epiphany, so i don't
really care :), but that's not nice)

Concerning .desktop files, i don't think there is anything to do,
caching the infos would bring no real advantages, the number of files is
too low.

Comments, suggestions, etc ?
(lease keep the debate 'python will eat your ass' closed now, we *know*
python eats memory, cope with it)

For the deskbar team,

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]