trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2012

Re: [trinity-devel] Poll

From: Kristopher John Gamrat <chaotickjg@...>
Date: Sun, 12 Feb 2012 15:33:11 -0500
On Sunday 12 February 2012 02:56:08 pm Darrell Anderson wrote:
> > The primary downside (for me) of TDE when compared to
> > Fluxbox and LXDE is speed -- both Fluxbox and LXDE are
> > faster with the initial loading, and with loading apps when
> > my CPU is under stress; TDE apps are slow loading compared
> > to LXDE when my CPU usage jumps up, but they are both
> > roughly equal under light load. (I can do some testing on
> > this and provide results once I have my new hard disk)
> 
> Tim, a while ago you asked for recommendations for post R14 goals. I'd like us to address this issue.
> 
> There are a few bug reports addressing speed concerns: 258, 283, 693, 699, 731, and 760 for example.
> 
> Yet, even in the pre KDE4 days, KDE3 had a reputation for being slow and bloated. Whether fully true or false is not the point because the reputation exists one way or another. I can attest that KDE3 has always been and Trinity is slow on old hardware. I suspect the problem with old hardware is the hard drive and bus speeds.

I remember running KDE3 on "old" hardware, e.g. 256MB RAM and a 1ghz CPU. I've heard people say it works fine on 128MB RAM and 700mhz if you run a minimal install. I doubt many people would be using such hardware, but it's definitely possible and needs consideration.

My best suggestion (this will probably take several releases) is to see how much the code can be trimmed without removing functionality, possibly separate packages further for a sort of "old computer" install -- for example (though I can't say for sure, I personally never checked, don't take my word for it unless one of the devs can confirm), some of the libs from tdelibs probably wouldn't be needed for an absolute barebones system. It may also be good to try to separate functionality where possible.

Needless to say, we don't have to take that to an extreme, otherwise packagers might end up having to build 1,000,000 packages, and download times would slow down since the package manager has to send individual requests for individual packages through the DNS and all the way to the server and wait for individual responses. But definitely something to consider.

(now back to our regularly schedule topic ;-) )

-- 
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/

Attachments: