setting start-process environment, too much GC, debugging XEmacs

[stephen at xemacs.org]

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.