11:06 a.m.
Another possibly silly question arising from perusal of the great Mule
merge...
Is speed (or small linear factors in memory) ever actually a concern
nowadays? The whole deal of supporting multiple internal buffer
formats seems to be justified by speed for multi-lingual processing,
and there are various tricky things scattered around the rest of the
code to improve speed.
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.
(The days when a full compile was a go-out-for-long-dinner job rather than
a you-may-just-have-time-to-make-coffee job.)
On the other hand, I don't do extensive non-English processing.
Do people find XEmacs noticeably slow in any normal usage pattern?
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:45 p.m.
Julian Bradfield wrote:
Do people find XEmacs noticeably slow in any normal usage pattern?
Yes, GNUS.
I don't know exactly what happened, but Gnus got noticeably slower
somewhere around beta 26. It's been slow ever since. I tend to have
large folders, but before beta 26, it was acceptable. After beta 26 or
so, it became much, much slower. All on exactly the same machine and
same folder.
Reading some newsgroups is also noticeably slower, but I can't really
tell if it's because my news server is really slow or because gnus or
xemacs is really slow.
I don't know if this has any bearing on your Mule question, though. But
I am running Gnus and xemacs with mule enabled. It' rather nice to see
messages with the correct characters, even if I can't read them. :-)
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:22 a.m.
On Fri, Oct 31, 2008 at 6:45 AM, Raymond Toy <raymond.toy(a)ericsson.com> wrote:
Julian Bradfield wrote:
>
> Do people find XEmacs noticeably slow in any normal usage pattern?
>
Yes, GNUS.
Have you tracked this one down to a specific operation?
Gnus pushes emacsen to the envelope.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:56 p.m.
On Fri, Oct 31, 2008 at 11:06:17AM +0000, Julian Bradfield wrote:
Do people find XEmacs noticeably slow in any normal usage pattern?
Saving and loading is horribly slow with text files in the tens or
hundreds of megabytes. That's under mule (I haven't used a non-mule
xemacs in years).
Just objdump -D a reasonably-sized executable then load and edit the
result. Autosave is particularly annoying, with the lack of
asynchronous i/o.
OG.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:12 a.m.
On Fri, Oct 31, 2008 at 4:06 AM, Julian Bradfield <jcb+xeb(a)inf.ed.ac.uk> wrote:
Another possibly silly question arising from perusal of the great
Mule
merge...
Is speed (or small linear factors in memory) ever actually a concern
nowadays?
Yes. Absolutely.
We lost performance between 19.11/12 and 19.14
that no one was ever able to track down. I was assured
that it existed. I did not use 19.13 very much, and
of course, 19.14 was much slower and I only ran 19.12
after I took over from Chuck.
If you never take that into concern, you'll end up in
the Microsoft cycle. Every release bigger and slower
than before.
I am convinced that working set size -vs- CPU cache
sizes has something to do with it, but I do not know
how to prove it (and sadly, I am working on exactly
this same kind of issue at work right now so I can
only offer advice here).
If you've had a recent performance regression, bisect
it to the patch that caused it and back it out. Now.
Otherwise it will never get fixed, like the 19.11->19.12
or 19.1[12]->19.13 speed regressions.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:28 a.m.
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
5:28 p.m.
> 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.
True. I'd forgotten that. I used to have speed problems with VM, but
then I slightly modified my practices to keep folders below a
reasonable size (10-20MB), and the only time I notice is on the rare
occasions when I try to load the last 20 years' mail in one file
(which I don't do, since it doesn't work!).
I notice that if I do that (130MB folder, 30k messages), 21.4 and 21.5
have very different behaviour (with the same vm code).
21.4 loads the file quickly, and in some not too bad time enters
vm-mode. By then, it's using 180MB of main memory.
21.5 is slower to load, and is then a good deal slower to go into
vm-mode, after which time it's using 450MB.
But the most striking difference is generating the summary:
21.4 basically can't do it - on the basis of how it starts, it would
take weeks to finish.
21.5, on the other hand, generates the summary in reasonable time.
So it looks as if the difference is some quadratic vs linear
difference of the kind you mention. Would you have an idea what the
key difference between 21.4 and 21.5 would be, that removes the
terminal slowness of summary building?
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:32 a.m.
Julian Bradfield writes:
>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.
[...]
I notice
Thank you very much for all your careful noticing! No, I don't have
an idea why the two programs differ in the way you describe. One
possibility is that sometime around 21.5.26 Ben fixed the position
cache that is used to translate byte indicies to char indicies and
vice versa. I don't know if the cache is present and/or working in
21.4.
I'll try to get back to this later, but I have international travel
coming up.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:59 a.m.
possibility is that sometime around 21.5.26 Ben fixed the position
cache that is used to translate byte indicies to char indicies and
vice versa. I don't know if the cache is present and/or working in
21.4.
There is a cache in 21.4, but it later changed a lot.
The VM summary catastrophic slowness is present in 21.5.18, but not in
21.5.21 (19 and 20 both crash, so I couldn't try them).
Looking at the code, the cache code was considerably re-written beween
those versions. So was a lot of other stuff!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:32 p.m.
A little over ten years ago, I moaned about the fact that VM under
XEmacs 21.4 is uselessly slow when generating summaries for large mailboxes
(in the hundreds of megabytes region). Stephen said:
[Stephen:]
>possibility is that sometime around 21.5.26 Ben fixed the
position
>cache that is used to translate byte indicies to char indicies and
>vice versa. I don't know if the cache is present and/or working in
>21.4.
[me:]
There is a cache in 21.4, but it later changed a lot.
The VM summary catastrophic slowness is present in 21.5.18, but not in
21.5.21 (19 and 20 both crash, so I couldn't try them).
Looking at the code, the cache code was considerably re-written beween
those versions. So was a lot of other stuff!
Ben's new cache code would be a ****** to backport to 21.4, as he did
a huge amount of work, so I gave up.
However, today I discovered that I can trivially solve the problem,
simply by increasing the number of bufpos/bytind cache entries in the
21.4 code from 16 to 256. (Who, by the way, was responsible for
hard-wiring 16 and 15 in the code :-? )
Now VM can generate a summary of a 200MB mbox with a few tens of thousands
of messages in a few seconds (provided I increase the system stack
limit to allow garbage collection to work). Probably my performance
on smaller buffers is impaired, but who cares?
Steve, you might want to note for sxemacs.
2154
days inactive
5868
days old
9 comments
6 participants
participants (6)
-
Julian Bradfield -
Julian Bradfield -
Olivier Galibert -
Raymond Toy -
SL Baur -
Stephen J. Turnbull