On Sunday 12 February 2012 04:43:53 pm Darrell Anderson wrote:
> Tim mentioned in a previous thread something called tdeinit_phase1 that eventually will improve the Trinity start time. That's good news. :)
I'd be willing to test. Even on my "semi-new" hardware (~2.4ghz dual core with 4GB RAM), I'm still trying to tweak for performance ;-)
> > 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.
>
> There probably are places we can trim code. For example, do we want to continue supporting Cervisia, which is a KDE specific wrapper to CVS? I don't know.
Most people will want GUI apps for just about everything. When I was still new to Linux, I had actually considered designing a Qt app for the compile process (e.g. configure, make, install). Depends on whether or not there is enough demand for CVS support.
> Your comments run close to what I proposed a while ago: Trinity Light. The focus there is primarily knowledge about build issues. People using older hardware probably would not install tdesdk let alone build the package. Trinity Light likely would not include that package or at most, only as an optional package.
tdesdk is optional -- if it isn't needed to operate properly, it's optional. I don't have it installed on my TDE system because I currently have no use for it :-)
> Older hardware more than likely are standalone home or small-office machines. If we had a wiki page addressing such build issues we could offer a Trinity Light without sacrificing developer time toward tweaking code. All we need is information and then let packagers handle the details. Trinity Light is not something we support officially. That is, we don't provide the packages, we provide the information needed to build Trinity Light. We probably post to our web site that the basic Trinity installation runs best with hardware of PIII or faster and 512 MB RAM. For people wanting a lighter version we refer them to the build instructions at the wiki.
>
> The wiki page would address which build options could be removed and why. For example, building tdepim without sasl support builds a leaner package and theoretically faster KMail, but probably is a bad idea because that mechanism is how secure email logins are handled.
>
> My PI and PII qualify as old hardware and would serve as great test environments for running Trinity Light. :)
Definitely worth doing IMO. But even doing that, we could still probably trim the code a bit. I'm not talking which features to enable or which packages to install, I'm talking more of going through the code, removing what we don't need, and seeing what we could combine and/or reorganize (and if it would be practical to do so). The more the code can be shrunk without removing functionality or making the code difficult to work with, the smaller the binaries will be (in theory), and smaller binaries mean quicker load time, in theory at least. At a minimum, smaller binaries would (for the most part) mean less to load, which in turn means more RAM free (in general) for other stuff, or to at least more RAM for the loaded binaries to work with. As most anyone would tell you, RAM is generally the biggest factor in determining the speed of your computer (i.e. less swapping, since hard disks are slower than RAM).
I certainly wouldn't expect a small dev team to have made much progress by R14, but if it's doable, it's certainly worth considering.
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
Attachments: