Julian Bradfield writes:
Is speed (or small linear factors in memory) ever actually a concern
nowadays?
Yes.
Note that any linear algorithm with non-sequential buffer accesses
reduces to quadratic, unless you are quite lucky with position cache
hits. I'm pretty sure this hits us hard in code that keeps multiple
objects in unsorted order in a buffer (VM mail folders after
threading) and probably also in the extents code (the "wrap the whole
buffer in an extent and watch XEmacs sink slowly slowly in the
quicksand" phenomenon).
The whole deal of supporting multiple internal buffer formats
We don't. We currently support only the variable width format, and it
does slow things up, I believe. The code that looks like it supports
multiple buffer formats in theory could, but the alternative formats
have never been implemented.
The low-level variable-width code itself is quite tricky and I would
like to be able to simplify it by deoptimizing it. But for that we'll
need to have a reasonable alternative such as 8- and 16-bit buffers.
The last time I can remember being disturbed by XEmacs' slowness
was
sometime in the mid 90s when I was running Lucid Emacs 19 on a
68040.
In VM, I run into serious slowness every day; I'd like to just keep
all my VM folders as single files, but it's just not reasonable once
you get past about 20MB.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta