Re: --pdump
24 years, 6 months
Hrvoje Niksic
Hrvoje Niksic
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? :-)
- 2 participants
- 1 comments
Re: Speed of scrolling with a background pixmap
24 years, 6 months
Hrvoje Niksic
Hrvoje Niksic
Kyle Jones <kyle_jones(a)wonderworks.com> writes:
> Hrvoje Niksic writes:
> > [...]
> > Whether you use a bg pixmap or not, try comparing scrolling speed with
> > and without a bg pixmap. For me, scrolling is much slower without a
> > bg pixmap, even though the pixmap itself doesn't scroll.
>
> I assume you meant that scrolling is slower WITH a background
> pixmap.
Of course; sorry for the confusion.
> Repainting an X window with a pixmap is slower than clearing the
> same window to a single color. Repainting a window to a single
> color can probably be done with a single instruction sent to the
> video card. Repainting a pixmap region is going to require data to
> be copied from main memory to VRAM on the card.
Would it help if the X server be made to remember the picture? For
instance, is it possible to tell X that the letters are a layer over
the background image, which will be removed and replaced with new
ones? I assume the graphical 2D acceleration hardware has *some*
optimizations for these cases?
- 2 participants
- 1 comments
Speed of scrolling with a background pixmap
24 years, 6 months
Hrvoje Niksic
Hrvoje Niksic
Has anyone noticed how slow scrolling becomes when a background pixmap
is used? Let me define what I mean:
scrolling speed == press pagedown in a large buffer and let
auto-repeat do its work (fast auto-repeat assumed).
speed is the number of displayed pages per time
unit.
background pixmap == a background-pixmap used on the `default' face,
e.g. with set-face-background-pixmap, or with
XEmacs.default.attributeBackgroundPixmap X
resource. nothing fancy (e.g. having different
faces have different bg pixmaps is fancy).
Whether you use a bg pixmap or not, try comparing scrolling speed with
and without a bg pixmap. For me, scrolling is much slower without a
bg pixmap, even though the pixmap itself doesn't scroll.
Can you repeat that? Any ideas about the reason?
- 2 participants
- 1 comments
Re: --pdump
24 years, 6 months
Hrvoje Niksic
Hrvoje Niksic
Olivier Galibert <galibert(a)pobox.com> writes:
> > BTW, I notice that the hash-tables are "reorganized" after the
> > undumping. Why is that?
>
> Because the default method for computing hashes for lrecords is
> using the pointer itself. Since the pointers change, the hash
> values change and the position of the objects in the hash table has
> to change. Otherwise reads in the hash table fail randomly.
Then why store the hash-tables at all? You could just store a
hash-table's properties (weakness, hash function, etc.) and a list of
key-value pairs. After dumping, it is trivial to re-create the
hash-table -- see e.g. hash_table_instantiate().
Or, am I mistaken in thinking that creating a new hash-table from
scratch is healthier and faster than "reorganizing" an existing one?
- 2 participants
- 1 comments
--pdump
24 years, 6 months
Hrvoje Niksic
Hrvoje Niksic
I've just tried configuring with --pdump, and it worked. Of course,
the build process failed because make expected to see an `xemacs'
executable after dumping, but that's OK.
I tried running `./src/temacs', and I got a working XEmacs. Wow.
Almost unbelievable. :-)
BTW, I notice that the hash-tables are "reorganized" after the
undumping. Why is that?
- 2 participants
- 1 comments