Olivier Galibert <galibert(a)pobox.com> writes:
On Mon, Nov 01, 1999 at 03:52:19AM +0100, Hrvoje Niksic wrote:
> Have you tried measuring startup speed of XEmacs?
No. But I'm still in the <1s area for startup.
It only shows that you have a fast computer. :-)
> How long does it take to relocate the data?
Not much, obviously.
Why obviously? I think it should be measured, but I don't know what
to compare it against. Repeatedly timing `xemacs -batch -f kill-emacs'
might be a good measurement, given two XEmacsen with maximum
optimization.
Incidentally, a missing feature (which will be easy to implement
once I consider the rest of the system stable enough because it
needs some support in the build process which will have to call
temacs twice, once for dumping , once for relocating) is
pre-relocating the data to the address the initial mmap () puts the
file to. I'll do some tests, but I have no reason to think that it
should change between subsequence invocations of the same xemacs .
Are you sure about that? What gives you the guarantee that mmap()
will return the same address? I'm curious.
(Something that calls itself a "portable dumper" should be portable,
after all. OK, I couldn't resist this one.)
> Is the mmap()ed data shared between XEmacs processes?
Implicitely, which means not at all.
[...]
Yikes.
None at all because:
- the relocating process writes to most of the pages
- the garbage collector writes to the remaining ones
So, in order to have sharing we need the pre-relocation and a
smarter gc (which is probably going to come with Jan's allocator
model).
I'd *really* like Michael Sperber to comment on our GC discussions.
Michael, are you still around?
Ouch, there still are some nasty bugs in the pdump. Active regions
setup is lost . Same for auto delete selection. M-q breaks lines
in all the wrong places . And loses the line length, too, it seems,
while that may only be a side effect of not knowing where to break
the line.
Isn't that mail cute once filled by a pdumped XEmacs? ;-)
Feathers or lead? :-)