xfdesktop woes
Brian J. Tarricone
bjt23 at cornell.edu
Sat May 29 22:59:19 CEST 2004
Olivier wrote:
>On Sat, 2004-05-29 at 21:55, Brian J. Tarricone wrote:
>
>>personally, i'm against anything that requires the user to run a
>>separate instance of apps to get them to run on more than one screen. i
>>think that's a big waste of memory, and i'm surprised that you'd
>>advocate such a path for xfce, which prides itself on having a low
>>footprint.
>>
>>
>
>Come on, how many people run such a configuration? People who can afford
>such a configuration can afford the price of the RAM.
>
>
i really, _really_ hate it when people try to use this as an argument.
this is why we have bloated, inefficient, poorly-designed software all
over the place: because it's so easy to say that RAM/CPU upgrades/hard
drives are cheap.
sure, my design does tend to cater toward a smaller set of users that
have multiple monitors. however, i tend to think that the type of user
that has multiple monitors would be more likely to use xfce (after it
gets proper, complete multihead support) than something like gnome or
kde. gnome and kde are (in general) for the "average" linux user
(whatever that is). the absolute-minimalism junkies will continue to
use open/black/whatever-box. the people in the middle, who like a DE
that is fast and doesn't waste resources, and who don't mind a little
loss in integration and ease of configuration, will use xfce. i tend to
think that the people who have multiple monitors fall into the xfce
category moreso than others. sure, that's an unfounded, baseless
statistic - it's just my feeling on the matter. but i'm not going to
change my mind on that unless i see stats to the contrary.
just for some real-world numbers: right now i'm running feb 12th
xfdesktop CVS, with the menu module backported. top reports total VM
size as 13.8MB. next i take my latest (albeit somewhat-broken)
xfdesktop version, that has the multihead support with the design i
mentioned in my last email. total VM size: 14.1MB. both are with a
single desktop image with a gradient. my design causes a 2% memory
increase. in my opinion, that's a perfectly valid tradeoff for design
simplicity and elegance, as well as eliminating the need to run an
instance of xfdesktop per screen. as i also, said, there is room to
optimise, and i think it's possible to get my design to be almost
indistinguishable from the original from a memory standpoint. (of
course that these numbers are somewhat rough and shouldn't be taken as
gospel.)
>BTW, the "overhead" of running multiple instances of an application is
>not that much, most modern system share the code in memory when more
>than one instance is running.
>
>
i was under the impression that this is the case for shared libraries,
but not normal static binary code. please correct me if i'm wrong.
>Speed is more important than memory footprint. Saving memory is not a
>goal by itself, it's interesting because it makes the system feel faster
>(as less memory gets swapped to disk).
>
>
in this case "feel faster" = "faster". hard drives, as secondary
memory, are dirt slow. i think any opportunity to reduce memory
footprint should be taken, if the goal is to decrease swapping. in the
most general sense, a low-memory application is faster than high-memory
application. your opinion obviously differs from mine, but i don't see
much of a distinction between "speed" and "memory footprint" when my
goal is to make something "lightweight".
i like my multihead-xfdesktop design. i think it's a sound, simple,
elegant design, and it thus far runs quickly and without a significant
amount of extra memory. some tweaking and optimisation may prove to
reduce that further. assuming i can resolve the app-crashing issues, i
intend for xfdesktop 4.2 to use this design, barring any changes to
xfce-mcs-manager or other xfce backend features that may make another
design better (in my opinion). if this is a problem, then.... well,
then we have a problem. i don't mean to be confrontational, but i've
put a lot of work into this, and i feel very strongly that i'm going in
the right direction.
-brian
More information about the Xfce4-dev
mailing list