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 (hopefully). > > > > * 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 Ass. 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 mini-commander. 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, Raf
Attachment:
signature.asc
Description: This is a digitally signed message part