Recent Features
| |||||||||||||
LinuxCon: A tale of two bootchartsLinuxCon: A tale of two bootchartsPosted Aug 26, 2010 4:20 UTC (Thu) by neilbrown (subscriber, #359)Parent article: LinuxCon: A tale of two bootcharts
> A more far out possibility avoids reading in the classes at all and loads
> the heap as a binary blob, though this would take the most development > effort and would require a rebuild when new classes are installed.
Brings back memory of building EMACS back in the '80s. In the last stage it would fire up the newly compiled emacs, load all the elisp files, then dump core. A support tool would combine the core file with the original binary to create a new binary which had the compiled elisp already loaded in the data section.
LaTeX did that too I think.
Everything old is new again!
(Log in to post comments)
LinuxCon: A tale of two bootcharts Posted Aug 26, 2010 4:58 UTC (Thu) by rsidd (subscriber, #2582) [Link]
"Hibernate" seems to be the ultimate core-dump: dump all of memory to the disk, and reload it on power-up. However, I haven't yet used a linux machine where resuming from hibernate was faster than a fresh boot. (Even on Windows, there isn't much difference). The main advantage is that it preserves the state of the system: if I factored in the time to open all the programs I have, reload all documents, webpages, etc, hibernate would be a big win.
Luckily, on my current laptop, "sleep" (suspend-to-ram) works very well, so I rarely do anything else.
LinuxCon: A tale of two bootcharts Posted Aug 26, 2010 14:30 UTC (Thu) by Fowl (subscriber, #65667) [Link]
<OT>
I've always found hibernate on Windows to be significantly faster than a fresh boot. Perhaps I'm stuck with hardware that is too low end though - 1GB of IO is faster than 4GB of IO shock horror!
Sleep (and "Hybrid Sleep", aka suspend to ram + hibernate) _are_ marvellous, barring any firmware SNAFU's.
LinuxCon: A tale of two bootcharts Posted Aug 26, 2010 5:39 UTC (Thu) by thedevil (subscriber, #32913) [Link]
Back in the 80s? It still does precisely that AFAIK. Other programs which provide both scriptability and a built-in core written in the scripting language do something similar, or else they just ship the core blob in the source (hello ocaml!)
LinuxCon: A tale of two bootcharts Posted Aug 26, 2010 9:52 UTC (Thu) by liljencrantz (guest, #28458) [Link]
The difference is that back in the 80s, a lot fewer people used prepackaged emacs.
LinuxCon: A tale of two bootcharts Posted Aug 26, 2010 18:01 UTC (Thu) by iabervon (subscriber, #722) [Link]
I thought emacs switched at some point from actually dumping core to more explicitly byte-code compiling the elisp and writing it to files, on account of needing a substantial chunk of optional elisp from a very large library when starting up; dumping only the fundamental stuff was still too slow, and dumping everything would require reloading too much, so they needed a quick way to load individual modules, and this obsoleted the core dump mechanism. But I could be wrong; it's been ages since I've actually watched emacs build.
LinuxCon: A tale of two bootcharts Posted Aug 26, 2010 22:47 UTC (Thu) by nix (subscriber, #2304) [Link]
Emacs did that for a long time, then both Emacs and XEmacs shifted to a more explicit serialization mechanism (the resulting files are mmap()ed in, so still shared between instances IIRC), mostly because keeping unexec() working was a pain.
LaTeX never did the coredump trick because it wasn't originally written on a Unix system at all (hell, it's written in Pascal). It's always written out a serialized representation of its state ('format files') then loaded them later. I'm not sure how valuable this is for LaTeX proper anymore (who cares about a fraction of a second?) but it's very valuable for big formats like ConTeXt, which takes ages to load even on modern systems.
LinuxCon: A tale of two bootcharts Posted Sep 2, 2010 11:20 UTC (Thu) by jschrod (subscriber, #1646) [Link]
For LaTeX it is still of interest in special circumstances where one preloads classes and packages as well and then dumps the fmt file.
In a current project of mine, I was able to improve the format time of a document from 4 sec to 0.4 secs with usage of such a format file. It's not much for one document, but since (a) we're producing ca. 15 million documents a year and (b) this is also used in an interactive environment, such performance improvements were very well received by our users.
|
|||||||||||||