Speed suggestions (previously about laptop performace)
- From: David T.Bath <David Bath auspost com au>
- To: gnome-list gnome org
- Cc: hobbit aloss ukuu org uk
- Subject: Speed suggestions (previously about laptop performace)
- Date: Fri Aug 2 15:17:22 2002
On 02-Aug-2002 Telsa wrote
> GNOME speed (or lack of it) concerns me. Although this is slightly
> separate from the broader issue of "GUI performance on laptops
> running Linux".
Apparently, the KDE3 speed improvement was due in no small part to
a mem-leak-killfest using a kde memory profiler/debugger that had
just been developed.
Maybe a similar festival could happen for Gnome stuff using memprof?
I'd imagine the KDE teams will be happy to tell you how they
organized their fest.
To me, both KDE and Gnome seem to have many filehandles open, usually
to config or temporary files. This can push system limits when there
are a number of users on the box, and you have to kill the more long-lived
sessions and/or fiddle under /proc/sys. GConfig might help solve this
problem.
However, I believe the problem both for Gnome and KDE is that users
have little idea which tools are quality products (Gimp, Konqueror)
and which use Gnome/KDE APIs, but are poorly written with consequential
performance drops.
This could be addressed by a vetting process, with a "star" scoring
system administered by respected people, checking for basic good
behaviour in programs. Just because it *looks* like a flashy Gno
or KDE app does *not* mean it is well written.
Years ago, the source of all good things was comp.sources.unix,
and we could not get our code in there unless it conformed to
certain standards, and the administrator (Paul Vixie at DEC)
had eyeballs the code for malice/stupidity. This provided
discipline when we contributed, confidence when downloading,
and justification to managers, who had even less idea of the
advantages of open source than they do now. (How do you get
below -274 degrees Kelvin?)
Thus, while technical improvements are necessary, organizational
expertise (and most of us are *hopeless* in that domain) is
also required.
Sorry about being less active over the last year or so, I've been
unwell.
--
David T. Bath, EDIPost
+61-3-9204-8713 0418-316-634
David Bath auspost com au
RFC does not stand for Richmond Football Club
#include <std/disclaim.h>
Australia Post is committed to providing our customers with excellent service. If we can assist you in any way please either telephone 13 13 18 or visit our website www.auspost.com.au.
CAUTION
This e-mail and any files transmitted with it are privileged and confidential information intended for the use of the addressee. The confidentiality and/or privilege in this e-mail is not waived, lost or destroyed if it has been transmitted to you in error. If you have received this e-mail in error you must (a) not disseminate, copy or take any action in reliance on it; (b) please notify Australia Post immediately by return e-mail to the sender; and (c) please delete the original e-mail.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]