Bugzilla – Bug 112654
SUPER: preloading data for faster application startup
Last modified: 2005-08-25 14:14:27 UTC
As part of the SUPER project I have developed a system for preloading application-data in the background to speed up the startup of certain applications. The webpage for my part of the SUPER sub-project is at [1]. Please also note the benchmark results at [2] (now removed because Andreas Girardet wants a unified standard benchmark). The patch is -very non-intrusive: only adds 6 textfiles + 1 small shellscript -improves startup times a lot: E.g. OpenOffice went from 17 seconds down to 6!!! I think that this adds a great benefit for desktop users! My suggestion is to add my files to the already existing "preload" package. Please tell me if you can put it on Beta4 so it receives wider testing. I know it is a little late to add new features, but this one is very simple and has great benefits. [1] http://www.opensuse.org/index.php?title=SUPER_preloading [2] http://www.opensuse.org/index.php?title=SUPER_preloading&oldid=1404
Sounds like sth. for Coolo.
note that half the info on that page is wrong as we redone the preload package. But I took over your files in the package
The info is based on openSUSE beta2. You really redid the preload package for beta3? If so, where can I get it?
Created attachment 47349 [details] RPM
Not even for beta3.
there is a bug in the .sh script now, the files have to be used from /var/cache/preload/
You got me confused now: Do you mean that preload 0.2.2 was not finished in time for beta3 but will be in beta4 and final? This is at least how I understand you. Another question: I also provide an autostart file for KDE and a preloader.sh which you have not included into your package. Can you include that into preload as well or should I ask the KDE people about it?
I second the more aggressive preloading Stfan suggests. I also would suggest to create a boot.preload and do this very early on in the boot process as the login time is hugely affected by having a .desktop file. Doing it very early on in the bootprocess allows preload to catch up time when the USB/dev stuff is happening and counting down .... I know this would break the ability to preload if /usr is mounted via NFS.Maybe a boot.preload should check for that and not run in such a case. I have personally in 15 years UN*X experience not seen any place doing that however. Seems like an old UN*X tradition, that is not really used on modern desktops. Ideally the preload information should also be gathered dynamically by having some kind of preload daemon gather such information from the application a user is running. I don't know if that is possible or if such a daemon would possibly hit the performance of the system hard, but a dynamic creation of the files would be excellent. That would also allow us then to think how those files could be stored on disc in a manner that the preload/disc seeking is fast.
We do this already starting with the next beta. Btw, note that due to a timing error in finishing beta3, the new preload rpm is already included, but not dependend package (like earlykdm or the boot scripts, which need new dependencies) were included. The effect is, that preload effectively is not used in beta3 :-( Just so you don't wonder.
still, it's in there