Re: setting start-process environment, too much GC, debugging XEmacs
Nix writes:
I *always* forget `process-environment', and for some reason I
never
remember to hyper-apropos for it...
Well, it *should* be in the docstring for `start-process', for
heaven's sake, but it ain't. Doc fix forthcoming. While I'm thinking
about it, is there anything else that we omit reminding you about in
process handling? :-)
Aside: the new GC, um, doesn't, despite running. After half an
hour
using Gnus:
RSS VSZ COMMAND
499000 789848 xemacs
`Eight hundred megabytes and constantly swapping.'
Hrm. Adrian reported this and I thought Marcus fixed it. But that
may be post-21.5.27. When you say "21.5.27", do you mean tarball
and/or cvs co -r r21.5.27, or do you mean CVS HEAD and that's what
`emacs-version' tells you? Unless you're CVS-challenged for some
reason, I strongly recommend using CVS HEAD---there's very little
risk, as nobody is committing megapatches at the moment. Stability is
essentially monotonically increasing.
> > One aside: if XEmacs goes into a tight loop, how do I
debug it?
> > I entered a newsgroup a few minutes ago and XEmacs wandered off
> > computing madly, GCing occasionally, and never came back.
It did come back. It just took two hours.
I suspect this is an example of the `noticeable slowdowns' of
--with-assertions.
That's possible. Many algorithms go quadratic in buffer size because
of error-checking on the position cache. If the position cache is
getting lots of hits, it will only be linear, but a lot of Gnus's
algorithms, as well as fontlock which Gnus uses heavily, seem to loop
over all buffer positions repeatedly. That destroys locality, of
course, and the position cache is useless.
You could try configuring --with-error-checking=all,nobufpos.
Aha! Lots of other nifty stuff in there too, thank you!
My pleasure, sir.
Does building with -g3 help? (That includes macro information in the
debugging info, and makes that debugging info quite a lot larger in
the process.)
You tell me. (I'll try it in a few days, but the most real work I can
do for the next couple is fixing docstrings. :-)
I suspect the GCC version number bump is because that's about
when GCC
stopped using stabs debugging info by default on most ELF platforms and
switched to DWARF2.
Ah, I noticed that but I didn't know what it meant.
(You can still generate stabs debugging info with
-gstabs, and stabs debugging info with macros with -gstabs3, but there
is rarely a need for that unless you're cursed with old debuggers.)
How old? Mac OS X 10.3 uses a v5.3 gdb, and "cursed" doesn't begin
to describe the way I feel half the time (and I don't even ever try to
debug C++ :-( ).
I've had quite a lot of experience picking Gnus code to bits (at
least
enough to figure out how to advise its more gory functions: I have a
rather complex Gnus configuration). If it does turn out to be Gnus's
fault, I think I can send a bug report and/or patch to Lars.
I don't think we can talk about "fault" here. Gnus and XEmacs just
don't think the same way AFAICT. But anything you can do to improve
Gnus performance (or get our AUCTeX package up to current DAK version
;-) would be greatly appreciated.
I'm not kidding about the AUCTeX package, by the way, but before
anybody does significant work, notify at least me and Uwe Brauer,
because we both have interest and experience along those lines.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta