September Gnus 0.40 is released

September Gnus 0.40 is released

[Lars Magne Ingebrigtsen]

Bug fixes.

Get it from <URL:http://www.ifi.uio.no/~larsi/sgnus.tar.gz> or 
"ftp.ifi.uio.no:/pub/emacs/gnus/".

ChangeLog since last release:

Wed Feb 21 00:21:56 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* gnus.el (gnus-summary-refer-parent-article): Also check the NOV
	references. 

	* gnus-salt.el (gnus-possibly-generate-tree): Don't generate trees
	for pseudo-articles.

	* nnvirtual.el (nnvirtual-retrieve-headers): Make sure the group
	exists. 

	* gnus.el (gnus-summary-read-group): Search all frames when
	recentering the group buffer.
	(gnus-summary-hide-thread): Didn't hide dummy threads.

	* gnus.el (gnus-summary-prepare-threads): Dummy roots would
	swallow the following article.

	* gnus-msg.el (gnus-new-empty-mail): New function.
	(gnus-summary-resend-bounced-mail): Use it.

	* gnus-picon.el (gnus-picons-display-x-face): Make sure buffer
	exists. 

Tue Feb 20 04:45:34 1996  Lars Ingebrigtsen  <lars@eyesore.no>

	* gnus.el (gnus-group-set-current-level): Error if not a group on
	the current line.
	(gnus-summary-next-page): Don't go to the next article when 'never
	and at the end of the group.
	(gnus-group-make-group): Make sure the server is opened.
	(gnus-read-descriptions-file): Make sure the method is a method
	and not a server.

	* gnus-msg.el (gnus-copy-article-buffer): Ditto.
	(gnus-forward-insert-buffer): Ditto.

	* gnus-cite.el (gnus-cite-parse): Use `gnus-set-text-properties'.

	* nnheader.el (nnheader-temp-write): Would bug out on nil files. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: September Gnus 0.40 is released

[Steven L Baur]

nnbabyl.el still has an unprotected call to set-text-properties.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: September Gnus 0.40 is released

[Per Abrahamsen]

This emacs is reserved for Gnus:

  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
 6037 abraham   23    0   14M   13M sleep  15:42  0.13%  0.13% emacs

This emacs is for development (cc-mode, gud, ediff, vc, and compile):

  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
  975 abraham   33    0   11M 8032K sleep  30:36  0.00%  0.00% emacs

Just for comparison:

  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
22473 abraham   34    0   12M 5372K sleep   8:55  0.00%  0.00% netscape

The Emacs is an 19.31 pretest.  The Netscape is 1.1N.  

Acceptable?  I guess that depends on how much memory you have.  

My boss thinks that giving developers enough memory helps
productivity, so as long as nobody tells him that it just makes us
write bloated software, I don't have a problem.

Re: September Gnus 0.40 is released

[Steven L Baur]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

Per>   PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
Per> This emacs is reserved for Gnus:
Per>  6037 abraham   23    0   14M   13M sleep  15:42  0.13%  0.13% emacs
Per> 22473 abraham   34    0   12M 5372K sleep   8:55  0.00%  0.00% netscape
...
Per> Acceptable?  I guess that depends on how much memory you have.  

Per> My boss thinks that giving developers enough memory helps
Per> productivity, so as long as nobody tells him that it just makes us
Per> write bloated software, I don't have a problem.

As does my boss.  I'm also inclined to agree with you that memory
usage with GNU Emacs is within acceptable limits.

A comparison with Netscape is fair, although a better metric would be
against 2.0 instead of 1.1N.  Whatever the difference, there is no
comparison with respect to functionality, Gnus + X?Emacs wins no
contest.

A hard choice has already been made to abandon support for earlier
versions of Emacs.  Are we also prepared to abandon lesser endowed
systems as well?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: September Gnus 0.40 is released

[Andy Eskilsson]

/ Steven L Baur <steve@miranova.com> wrote:
| 
| A hard choice has already been made to abandon support for earlier
| versions of Emacs.  Are we also prepared to abandon lesser endowed
| systems as well?

This shouldn't stop us(ehm the Gnus developers) from keeping eyes open
for memory leaks, memory hogging stuff that really ain't worth it?

I don't know much about the memoryhandling in emacs/gnus, but I think
you are talking about two different memory-hogs here:

1. Memory leaks (I think it is possible!), features that take a large
   hunk of memory, that they(the user/feature) might not need.

2. Feature 'leaks', simply more features, more memory.

I think this thread started with the first point, and Steven is
talking about the second?

	/andy (on his 386sx16 with 1 meg ram.. ehh, hoold it..)

-- 
 Don't walk in front of me, I might be unable to follow you.
 Don't walk after me, I might be unable to lead you.
 Just walk by my side and be my friend.

Re: September Gnus 0.40 is released

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@miranova.com> writes:

> A hard choice has already been made to abandon support for earlier
> versions of Emacs.  Are we also prepared to abandon lesser endowed
> systems as well?

No -- especially since this is being typed on a Linux bux with 6 megs
of ram.  :-)  (It's where I do 90% of my work.)  I find that when
just running Gnus and reading small groups, it usually doesn't grow
beyond 4 megs, which leaves room for gnus.el and gnus.texi and stuff
without trashing.  Entering a group with 2000 articles is totally out
of the question, though.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: September Gnus 0.40 is released

[d. hall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----

ð thus on 22 Feb 1996 02:12:47 +0100, Lars virtually scripted...

Steven L Baur <steve@miranova.com> writes:

>> A hard choice has already been made to abandon support for earlier
>> versions of Emacs.  Are we also prepared to abandon lesser endowed
>> systems as well?

Lars> No -- especially since this is being typed on a Linux bux with 6 megs
Lars> of ram.  :-) (It's where I do 90% of my work.)  I find that when just
Lars> running Gnus and reading small groups, it usually doesn't grow beyond
Lars> 4 megs, which leaves room for gnus.el and gnus.texi and stuff without
Lars> trashing.  Entering a group with 2000 articles is totally out of the
Lars> question, though.

Okay call me spoiled (hmm... I might actually spell check this article
since it's a subject near and dear to my heart) in that I think 16 megs
isn't enough.  Just a year and half ago I was tinkering around with a 486
dx2/80 with 4 megs of ram and thinking it was hot s**t (now with 16 megs
I'm beginning to wonder with the current crop and trend with software if
even _that_ is enough to "scratch by").

I've been doing some checking, the main problem seems to be when I try to
access some of the higher volume newsgroups, namely comp.lang.c (with
_heavy_ adaptive scoring).  If I leave off reading that newsgroup for a
couple days I'm sacked with a couple thousand articles that Gnus needs to
parse through, and I'm leery to leave that emacs process running after I
read that newsgroup.  So a possible option includes a "stealthing
procedure" for the newsgroup (which probably pertains to asynch reading of
the overview files).  Basically catching "snippets" of the overview file in
gnus-large-newsgroup sections.  I'd be willing to trade time for memory
usage in matters like this, also it'll break the waiting time into
segments.

Also I've looked into reducing of the overall feature loading in default
Gnus.  I've been doing some extensive feature tree studying in the last few
days to trace where all my memory is going.  The features variable grows
exponentially with each little Gnus feature I like to try out.  Inherently
I'm a minimalist, and like to load just what I need and use.  I'm don't use
nnmh, and yet this needs to be loaded with nndraft, which I like...  which
presents problems.  I do use nnfolder, and would love to have nndraft use
nnfolder instead of nnmh, possible in future releases (Red Gnus)?  I don't
know if nndraft would be considered a back-end in and of itself or a
back-end "wrapper" to another back-end.  The feature tree grows with X
interface, but that is to be expected.  I don't think Gnus can be broken
into any smaller files to reduce feature overhead =).

To give an extent of how bad minimalism can get, I've deleted most of
loaddefs.el and re-did the update after deleting 25% of the lisp directory
(well this and the fact that some idiot put the IDE cable backwards into my
western digital 1.6 gig hard-drive, thereby frying it, and reducing me to
my .5 meg Maxtor hard drive and further leaving me in a crunch for disk
space right now).

d.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMSwnzYX26urqpgG1AQFjugQAhUaWb5cflx35uTsK+Boi5EEAQrYUjMLM
D3CPby6JydArBAQD4qQ9pMARwyVa+TXJPtYpo8OHmoVjxLMklf/eWzP9xNhbDoy8
nbPKbb1fbtOkwnBJXhhiB22nfMob+jgXX6NwnrktOfhMVdWjNSIAohmO6JcxhFzC
njbdbIC1NHk=
=2z2n
-----END PGP SIGNATURE-----
--
Hi!  Darren's answering machine is broken.  This is his refrigerator.
Please speak very slowly, and I'll stick your message to myself with
one of these magnets.
				~ answering machine message

Re: September Gnus 0.40 is released

[Lars Magne Ingebrigtsen]

dhall@illusion.apk.net (d. hall) writes:

> So a possible option includes a "stealthing procedure" for the
> newsgroup (which probably pertains to asynch reading of the overview
> files).  Basically catching "snippets" of the overview file in
> gnus-large-newsgroup sections.  I'd be willing to trade time for
> memory usage in matters like this, also it'll break the waiting time
> into segments.

Reading the nov file doesn't make Emacs increase in size much.
Generating the summary buffer does.  Gnus creates all kinds of odd
thread trees (3 cons cels per article), a `gnus-newsgroup-data' list
(5 cons cells per article), and all those text properties that make
the summary buffer look all pretty an nice (I have no idea how many
cons cells). 

If you enter a group with 10000 unread articles, all those small cons
cells do add up.

> I'm don't use nnmh, and yet this needs to be loaded with nndraft,
> which I like...  which presents problems.

nndraft is a wrapper around nnmh, so you need both loaded.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: September Gnus 0.40 is released

[Steven L Baur]

(Two articles I posted Wed 21-Feb, (about 21 hours ago) were damaged
by an experimental recompiled XEmacs, this article should be O.K.)

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> Reading the nov file doesn't make Emacs increase in size much.
Lars> Generating the summary buffer does.  Gnus creates all kinds of odd
Lars> thread trees (3 cons cels per article), a `gnus-newsgroup-data' list
Lars> (5 cons cells per article), and all those text properties that make
Lars> the summary buffer look all pretty an nice (I have no idea how many
Lars> cons cells). 

Let's see.  Add to that the text properties of fancy citation
highlighted text, *Group* buffer color schemes ...  There must be some
room for reusing extents intelligently on XEmacs though.  Once the
code starts to settle down, this sounds like a worthwhile project.

Regards,
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: September Gnus 0.40 is released

[d. hall]

-----BEGIN PGP SIGNED MESSAGE-----

One strange note, I'd like to bring up since all this NNFOLDER talk has
been occuring.  I ran list-buffers at one time and found all my nnfolder
files open in their own buffers.  I did a C-h v on nnfolder-always-close,
which was t.  Right now my emacs is bloated to the point where at times
when running Gnus it'll eat up 8 megs of my 16 meg linux.  I'd really
rather not have to swap all my processes to read news, any suggestions on
reducing this?

d.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMSqcJ4X26urqpgG1AQF8DgQAlTViR6+Hwqhkg0rJaGrBa5+hSk+TnBO2
6rcVWTenhcGEqWbR4U5Z2YZBc3RC1hzNLm15JJopEAV/bhi7PntxhuP97meJ0j38
dP+9FYUi/pQHXklQIVlypQCHUCcw81H1RKy4GV2aGaA8QQIl8cA6SqILAyP3tluy
Z9JFar18FXo=
=BZ7E
-----END PGP SIGNATURE-----

Gnus Memory usage

[Steven L Baur]

>>>>> "d" == d hall <dhall@illusion.apk.net> writes:

d> One strange note, I'd like to bring up since all this NNFOLDER talk has
d> been occuring.  I ran list-buffers at one time and found all my nnfolder
d> files open in their own buffers.  I did a C-h v on nnfolder-always-close,
d> which was t.  Right now my emacs is bloated to the point where at times
d> when running Gnus it'll eat up 8 megs of my 16 meg linux.  I'd really
d> rather not have to swap all my processes to read news, any suggestions on
d> reducing this?

I'd love to have a Gnus stay down at only 8 MB, but let me quantify my
numbers.

This is from a Linux 1.2.13, ELF system, output slightly reformatted
to align the columns.  And yes, I have enabled the allocator that can
return memory to the system.

ps -ux output:
USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
steve     2148  2.8 18.3 4899  5724  ?  S    11:39  18:21 /usr/local/bin/xemacs
steve     7329 29.6 39.8 9327 12408  ?  S    19:30  53:39 /usr/local/bin/xemacs

ps -mx output:
  PID TTY MAJFLT MINFLT TRS  DRS   SIZE SWAP   RSS SHRD  LIB    DT COMMAND
2148  ?    1994   3431 1976  3968  6660  716  5944 1928    0   986 /usr/local
7329  ?     779 287486 1872 11208 13860  780 13080 2068    0  2753 /usr/local

PID 2148 is an XEmacs I've been editing in all afternoon.  PID 7329
has been running Gnus.  I consider this memory usage unacceptable.

The burning question is what does everyone consider acceptable and
normal Gnus+X?Emacs memory usage?

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Gnus Memory usage

[Wes Hardaker]

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

    Steven> This is from a Linux 1.2.13, ELF system, output slightly
    Steven> reformatted to align the columns.  And yes, I have enabled
    Steven> the allocator that can return memory to the system.

You know, I brought up this subject a while back (1 month?) and never
got many responses saying 'yeah me too'.  Its actually worse than you
think.  (FYI, I'm running 19.13 with re-alloc as well).  Even if you
quit gnus, you don't regain the memory, which is what I really don't
understand.

Wes

Re: Gnus Memory usage

[Lars Magne Ingebrigtsen]

hardaker@ece.ucdavis.edu (Wes Hardaker) writes:

> You know, I brought up this subject a while back (1 month?) and never
> got many responses saying 'yeah me too'.  Its actually worse than you
> think.  (FYI, I'm running 19.13 with re-alloc as well).  Even if you
> quit gnus, you don't regain the memory, which is what I really don't
> understand.

I thought (X)Emacs could only return memory that was allocated for
buffers?  That no cons cells (and stuff) were ever returned to the
system?  Has that changed?

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Gnus Memory usage

[Wes Hardaker]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    Lars> I thought (X)Emacs could only return memory that was
    Lars> allocated for buffers?  That no cons cells (and stuff) were
    Lars> ever returned to the system?  Has that changed?

You must think that I know something when I start typing out important
sounding sentences.  "HA" I say!

Anyway, I'm not sure honestly.  I would hope it would do as much as
possible, but I really don't know.  

All I know is that when I was doing experiments a while back (sgnus
.2? or .1? something I would think) and I started sgnus, I'd get a
massive memory increase.  Then I would quit sgnus and restart it
again.  I would get yet another memory increase.  This was sort of
annoying, since you get XEmacs to grow to a fairly large size simply
by reading news say 3 or 4 times during the day.  These were fairly
consecutive bursts; I should try this again and do things in between
the sgnus runs to see if anything gets cleaned up.  Maybe tommorrow (ha).

    Lars> -- "Yes.  The journey through the human heart would have to
    Lars> wait until some other time."

Whats that from anyway?  Sounds like it should be a great MST3K show
though.

Wes

Re: Gnus Memory usage

[Lars Magne Ingebrigtsen]

hardaker@ece.ucdavis.edu (Wes Hardaker) writes:

> All I know is that when I was doing experiments a while back (sgnus
> .2? or .1? something I would think) and I started sgnus, I'd get a
> massive memory increase.  Then I would quit sgnus and restart it
> again.  I would get yet another memory increase. 

That's definitely not good.  I'm running XEmacs at the moment, and it
is 13Mb big.  (But I did enter a virtual group with 4000 articles a
few minutes ago.)

>     Lars> -- "Yes.  The journey through the human heart would have to
>     Lars> wait until some other time."
> 
> Whats that from anyway?  Sounds like it should be a great MST3K show
> though.

It's from a short story by Janet Frame.  She's visiting some natural
history museum which has an exhibition on the human heart.  She stands
around listening to a guide explain something else to a bunch of
school children for too long, and she has to rush to catch a train, so
she doesn't have time to do the human heart exhibition.

Aren't you glad you asked?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Gnus Memory usage

[Wes Hardaker]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    Lars> It's from a short story by Janet Frame.  She's visiting some
    Lars> natural history museum which has an exhibition on the human
    Lars> heart.  She stands around listening to a guide explain
    Lars> something else to a bunch of school children for too long,
    Lars> and she has to rush to catch a train, so she doesn't have
    Lars> time to do the human heart exhibition.

    Lars> Aren't you glad you asked?  :-)

Yep!  Thanks.  It still sounds like it would make a great MST3K
episode.

Wes

Re: Gnus Memory usage

[Lars Magne Ingebrigtsen]

hardaker@ece.ucdavis.edu (Wes Hardaker) writes:

> It still sounds like it would make a great MST3K episode.

What's MST3K?  

Uhm.  Moon Seven Times...  No, that's M7x.   MMMSTK.  I give up. 

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Gnus Memory usage

[d. hall]

-----BEGIN PGP SIGNED MESSAGE-----

// thus on 24 Feb 1996 08:44:07 +0100, Lars virtually scripted...

hardaker@ece.ucdavis.edu (Wes Hardaker) writes:
>> It still sounds like it would make a great MST3K episode.

Lars> What's MST3K?

Lars> Uhm.  Moon Seven Times...  No, that's M7x.  MMMSTK.  I give up.

Mystery Science-Fiction Theatre 3000

It's a show that is/was(?) shown on Comedy Central a cable channel here in
the U.S.  It's one of those cult-following show, normally stereo-typed to
the "electronically inclined folk".  Not quite up there with Star Trek: *,
and I never really got into it.

d.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMS7Z3YX26urqpgG1AQGEoAP+NKu3eqxDhDqSUiYGI3FdxCxBVzUgzKTR
Q7I0BhRE6m+kAYIa5I/bhhbRnU3L2XsHso1jngCDe5iXQGCp+kZaGWGtAHbUXOAn
Pa/qx4aGDzsB7eTTVre2QHd/JdJVK7HUBwx/1ZoLwRKIdVhQt8gw86Jwz6CeEa6Q
eebJjMeXFBM=
=mM1e
-----END PGP SIGNATURE-----
-- 
        ``I don't know what's scarier. Losing nuclear weapons...
          or it happens so often there's actually a term for it.''

                                ~ from broken arrow

Re: Gnus Memory usage

[Stephen Peters]

dhall@illusion.apk.net (d. hall) writes:

Lars> What's MST3K?

>Mystery Science-Fiction Theatre 3000

Mystery Science Theatre 3000, but close enough :-)

>It's a show that is/was(?) shown on Comedy Central a cable channel here in
>the U.S.  It's one of those cult-following show, normally stereo-typed to
>the "electronically inclined folk".  Not quite up there with Star Trek: *,
>and I never really got into it.

OK, we're way off-topic here, but I'll just put my two cents in with a
little more information.  It is still being shown, although it may be
leaving the airwaves soon.  A big-screen version should be hitting US
theatres in April, I believe.

The basic idea is that they take a movie -- and I mean a really bad
movie, ideally with horrendous special effects and dialogue that makes
you wince, and they then make a running wisecracking commentary on the
film for its entire length.

I wouldn't say that it's stereotyped to "electronically inclined"
people -- the jokes are fairly reference-heavy, so I would say it
probably appeals more to people with a broad knowledge of pop culture
and a fairly sarcastic sense of humor.  It is, however, definitely a
cult show.  We'll see if it can translate at all well to the movie
theatre in April, I guess...

-- 
Stephen L. Peters                         speters%samsun@us.oracle.com
 For PGP key, use keyservers or send email with subject: SEND PGP KEY
      PGP fingerprint: BFA4 D0CF 8925 08AE  0CA5 CCDD 343D 6AC6
	Oracle won't speak for me, so I won't speak for them.

Re: Gnus Memory usage

[Wes Hardaker]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    Lars> What's MST3K?

As people have already said, it stands for "Mystery Science Theater
3000".  Its a show made in the U.S. and played on "Comedy Central",
which is a Television-cable channel produced by "HBO".

Anyway, the show is about this guy that two scientists shot into
space.  They make him watch really really really really (x inf) bad
Science Fiction Movies and study his reactions.

Ok...  Thats the story behind it.  The show is really about watching
this guy and 2 of his robot-friends heckle these bad movies.  You
watch the movie with them and you see their silhouettes on the bottom of
the screen (which is a silhouette of the front row of seats in a movie
theater).

They make wise cracks about these movies, which can on occasion be
really funny.  On other occasions, I've fallen asleep.  The movies
they are watch are truly bad.  Impressively bad.  If they can find
enough witty comments to make, they are worth watching though. 

Most people do seem to be either an avid fan or can't stand it.  I'm
one of the exceptions that fall in the middle.

Wes

Re: Gnus Memory usage

[Steven L Baur]

>>>>> "Wes" == Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

Wes> All I know is that when I was doing experiments a while back (sgnus
Wes> .2? or .1? something I would think) and I started sgnus, I'd get a
Wes> massive memory increase.  Then I would quit sgnus and restart it
Wes> again.  I would get yet another memory increase.  This was sort of
Wes> annoying, since you get XEmacs to grow to a fairly large size simply
Wes> by reading news say 3 or 4 times during the day.  These were fairly
Wes> consecutive bursts; I should try this again and do things in between
Wes> the sgnus runs to see if anything gets cleaned up.  Maybe tommorrow (ha).

Why kill and restart Gnus several times in the same XEmacs session?
The amount of time lost waiting for garbage collection as the size
increases easily surpasses the amount of time it takes to restart the
program from scratch.  It doesn't appear to hurt anything (if you have
the memory available) to just leave Gnus always running.
Disconnection is automatic, and reconnection is painless.

-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Gnus Memory usage

[Wes Hardaker]

>>>>> "Steven" == Steven L Baur <steve@miranova.com> writes:

    Steven> Why kill and restart Gnus several times in the same XEmacs
    Steven> session?  The amount of time lost waiting for garbage
    Steven> collection as the size increases easily surpasses the
    Steven> amount of time it takes to restart the program from
    Steven> scratch.  It doesn't appear to hurt anything (if you have
    Steven> the memory available) to just leave Gnus always running.
    Steven> Disconnection is automatic, and reconnection is painless.

Well, this is what I've started doing more lately.  Originally, I just
did it automatically thinking I wouldn't be reading news later.  It
was then that I noticed things got even worse during the second read.
At the time, I didn't read any mail inside gnus, so it was unusual to
read news twice in one day.  Again, I haven't checked this out in a
while so it may not happen anymore.

However, if it does shrink XEmacs to quit gnus, that alone might be
enough of a reason (though I think we've proven it doesn't shrink by
much).  When I'm actually trying to get some work done, my HP 715/80
with 96 megs of memory swaps constantly while running Mentor (a
bloated EE CAD program).  I often quit XEmacs all together before
starting Mentor.

blah blah blah
Wes

Re: Gnus Memory usage

[Mark Denovich]

> 
> Why kill and restart Gnus several times in the same XEmacs session?
> The amount of time lost waiting for garbage collection as the size
> increases easily surpasses the amount of time it takes to restart the
> program from scratch.  It doesn't appear to hurt anything (if you have
> the memory available) to just leave Gnus always running.
> Disconnection is automatic, and reconnection is painless.

Not so.  I am forced to use Dynamic-IP PPP.  Thus my IP address is
never the same after disconnect.  Sgnus and just about every other app
handle this very poorly, the exception being Netscape.

The solution is to kill gnus after the link goes down.  Starting it
back up when the net is back up.  I hope that it doesn't keep growing
every time I start-stop it, since do this at least 10 times a day.

I mentioned this to Lars sometime ago but don't know if he's doing
anything about it.  

	--Mark

Re: Gnus Memory usage

[Lars Magne Ingebrigtsen]

Mark Denovich <madst38@pitt.edu> writes:

> Not so.  I am forced to use Dynamic-IP PPP.  Thus my IP address is
> never the same after disconnect.  Sgnus and just about every other app
> handle this very poorly, the exception being Netscape.
> 
> The solution is to kill gnus after the link goes down.  Starting it
> back up when the net is back up.  I hope that it doesn't keep growing
> every time I start-stop it, since do this at least 10 times a day.
> 
> I mentioned this to Lars sometime ago but don't know if he's doing
> anything about it.  

I don't know exactly what I should do about it.  Gnus should
definitely figure out that something odd is going on when it sends out
commands and doesn't get any data back.  Perhaps the commands should
have a timeout thingie (which would not be enabled by default), and
if a command times out, Gnus should just hang up and reconnect.

Would that do the trick?

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

dynamic ip (Re: Gnus Memory usage)

[Felix Lee]

> Mark Denovich <madst38@pitt.edu> writes:
> > Not so.  I am forced to use Dynamic-IP PPP.  Thus my IP address is
> > never the same after disconnect.  Sgnus and just about every other app
> > handle this very poorly, the exception being Netscape.

the main reason netscape handles it is because http needs a new
connection for every data transfer.  netscape news handles dynamic ip
about as well as gnus does (automatic reconnect only on connection
shutdown).

Lars:
> I don't know exactly what I should do about it.  Gnus should
> definitely figure out that something odd is going on when it sends out
> commands and doesn't get any data back.  Perhaps the commands should
> have a timeout thingie (which would not be enabled by default), and
> if a command times out, Gnus should just hang up and reconnect.

this would be okay, but to be reliable the timeout would have to be on
the order of several minutes (since getting a response to a POST
command can take minutes).

what I'd like instead is an easy way of doing a manual reconnect,
since I know when I need to.
--

Re: dynamic ip (Re: Gnus Memory usage)

[Lars Magne Ingebrigtsen]

Felix Lee <flee@teleport.com> writes:

> what I'd like instead is an easy way of doing a manual reconnect,
> since I know when I need to.

`^' in the group buffer will put you in the server buffer.  `C' on a
server will close it and `O' will open it.  (There probably should be
a function to close/reopen all servers.  That's on the Red Gnus todo
list.) 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: dynamic ip (Re: Gnus Memory usage)

[Felix Lee]

Lars:
> `^' in the group buffer will put you in the server buffer.  `C' on a
> server will close it and `O' will open it.  (There probably should be
> a function to close/reopen all servers.  That's on the Red Gnus todo
> list.) 

hmm, ok.  though most of the time my connection hangs up while I'm in
middle of a batch command (like "Xu"), so that's a little
inconvenient.  restarting by hand means I have to restart the whole
transfer.

alternate approach: start up a keepalive process (such as "ping") to
check if the host is still reachable.
--

Re: Gnus Memory usage

[Mark Borges]

>> On 20 Feb 1996 22:55:11 -0800,
>> Steven L Baur(sb) wrote:
sb> I'd love to have a Gnus stay down at only 8 MB, but let me quantify my
sb> numbers.

Me too.

sb> The burning question is what does everyone consider acceptable and
sb> normal Gnus+X?Emacs memory usage?

This is on a 

	$uname -a
	SunOS suomi 5.3 Generic_101318-70 sun4m sparc

with numbers reported by top(1).

------------------------------------------------------------------------------
typical xemacs (both sgnus, VM running):

  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
25325 mdb      -14    0   14M   12M sleep   4:38  1.43% 13.69% xemacs-19.14-b

------------------------------------------------------------------------------
barebones(*) xemacs (xemacs -nw -q)
  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
15894 mdb       34    0 7004K 4848K stop    0:01  0.00%  0.00% xemacs-19.14-b

(*) You could build a smaller xemacs now by excluding toolbar
etc. support at compile-time, I think.

------------------------------------------------------------------------------
minimal xemacs (xemacs -q):
  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
15597 mdb       34    0 7232K 5700K sleep   0:03  2.24%  1.75% xemacs-19.14-b

------------------------------------------------------------------------------
minimal xemacs + my .emacs (efs,dmacro,fill-adapt,jka-compr,etc. required):

  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
15597 mdb       34    0 8436K 7032K sleep   0:12 11.18%  0.00% xemacs-19.14-b

------------------------------------------------------------------------------
minimal xemacs + my .emacs + sgnus:

  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
15597 mdb       34    0   11M 9352K sleep   0:37  3.30%  2.52% xemacs-19.14-b

------------------------------------------------------------------------------
immediately after quitting sgnus:

  PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
15597 mdb       34    0   10M 9076K sleep   0:38  2.36%  0.00% xemacs-19.14-b

------------------------------------------------------------------------------

However, if I kill off all the buffers and let xemacs run overnight,
when I return I the morning I find the RES size has shrunk to something
a bit less than 5Mb.

  -mb-