> > With > ftp://smarty.smart.net/pub/rlhamil/goodies/preload.c > you can load and optionally lock into memory files > listed on the > command line; with the proper choice of files, > browser startup > could be speeded up by a couple of seconds. > > That sort of feature should be automatic in the OS at > best, and at worst enabled in a GUI so users can > choose what apps to have preloaded (testing would be > done to determine the best files to preload, and then > you would choose "Firefox" in the GUI to have the > appropriate files loaded). > > DDR2 RAM is dirt cheap and very common. System > memory availability is increasing faster than > application size. Constant caching (rather than > caching after one run and then starting over after > powerup) is just another layer or type of caching > that would be beneficial to add to the mix, at least > for "powerusers" to use.
Well, I wrote it mostly to test what might make a difference (for me). If someone wants to figure out what's most worth caching for specific apps, be my guest. I suppose I could redo the program to take files containing lists of pathnames, rather than the pathnames themselves, so that one could make one such file per app. Of course, who would maintain those lists of files as apps were updated, that's another story. Ultimately, I think the apps themselves need work to speed them up; mine was just an external approach that sometimes helps a little without modifying anything. In particular, I think browsers could be speeded up if they behaved a little like CDE's dtpad editor, which has a "server" mode that it starts automatically if it's not already running on a desktop (or can be started in server mode by a login script) and a "client" mode that communicates with it. Netscape/mozilla/firefox (and I think OpenOffice/StarOffice, too) are already most of the way there in that one instance can be used to send commands to another instance. If it were possible to start an invisible instance during login, and just communicate with that to create new windows, startup could be made to appear nearly instant. The "Quick Launch" mode of mozilla on Windows actually did something very much like that, plus it put an icon on the "system tray" so one could control that behavior as well as have another way of opening a browser window. _That_ IMO would be the best solution to speeding application startup, and except for StarOffice/OpenOffice, I personally don't see that as specifically Sun's problem, but a problem generally affecting large app startup time on various Unix-like OSs. it's also one of the reasons why I personally favor mozilla/seamonkey over firefox+thunderbird; _one_ thing to get started rather than two, plus more sharing between them, plus more comprehensive interoperability between the two (I wonder for instance whether thunderbird supports being passed as much of the possible features of mailto: URLs as the integrated suite did within itself). Thus, if both seamonkey and OpenOffice had a "Quick Launch" like behavior for Unix/Linux, one would just see two icons somewhere to control that feature, and anything calling for any sort of application window from either suite would come up very quickly (although large or complex files could still take awhile to load/render/whatever). Now, if seamonkey could also read and present DocBook format documentation (without the need for something to HTMLify it first), such a quick-starting browser window arrangement could also make a nice documentation viewer. And if OpenOffice could edit DocBook SGML, then one could do the whole cycle. :-) This message posted from opensolaris.org
