Typos...

Typos...

[Andreas Jaeger]

I just noticed the following typos in the current CVS.  Interactive
use seems to be faster now but bootstrapping takes ages...

Andreas

2001-08-25  Andreas Jaeger  <aj@suse.de>

	* nnfolder.el (nnfolder-open-marks): Fix typo.
	* nnml.el (nnml-open-marks): Likewise.

Index: lisp/nnfolder.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnfolder.el,v
retrieving revision 6.15
diff -u -r6.15 nnfolder.el
--- lisp/nnfolder.el	2001/08/25 16:43:11	6.15
+++ lisp/nnfolder.el	2001/08/25 19:38:36
@@ -1219,7 +1219,7 @@
 		   (gnus-group-prefixed-name
 		    group
 		    (gnus-server-to-method (format "nnfolder:%s" server))))))
-	(nnheader-message 6 "Boostrapping nnfolder marks...")
+	(nnheader-message 6 "Bootstrapping nnfolder marks...")
 	(setq nnfolder-marks (gnus-info-marks info))
 	(push (cons 'read (gnus-info-read info)) nnfolder-marks)
 	(nnfolder-save-marks group server)))))
Index: lisp/nnml.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/nnml.el,v
retrieving revision 6.15
diff -u -r6.15 nnml.el
--- lisp/nnml.el	2001/08/25 16:20:26	6.15
+++ lisp/nnml.el	2001/08/25 19:38:37
@@ -949,7 +949,7 @@
 		   (gnus-group-prefixed-name
 		    group
 		    (gnus-server-to-method (format "nnml:%s" server))))))
-	(nnheader-message 6 "Boostrapping nnml marks...")
+	(nnheader-message 6 "Bootstrapping nnml marks...")
 	(setq nnml-marks (gnus-info-marks info))
 	(push (cons 'read (gnus-info-read info)) nnml-marks)
 	(nnml-save-marks group server)))))

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Typos...

[Simon Josefsson]

Andreas Jaeger <aj@suse.de> writes:

> I just noticed the following typos in the current CVS.

Committed, thanks.

> Interactive use seems to be faster now but bootstrapping takes
> ages...

It writes a few hundred bytes from memory to disk per group, that
shouldn't hardly be noticable unless you have a very slow network file
system or something.  Maybe something after the bootstrapping is
taking time, and the bootstrapping message is still in the minibuffer?

Re: Typos...

[Pavel Janík]

   From: Simon Josefsson <jas@extundo.com>
   Date: Sat, 25 Aug 2001 22:03:36 +0200

Hi,

   > > Interactive use seems to be faster now but bootstrapping takes
   > > ages...
   > 
   > It writes a few hundred bytes from memory to disk per group, that
   > shouldn't hardly be noticable unless you have a very slow network file
   > system or something.  Maybe something after the bootstrapping is
   > taking time, and the bootstrapping message is still in the minibuffer?

I also tried the new code - bootstrapping is a pain. It took about a minute
on my machine (Celeron 550/128MB/~40 nnfolder groups). Startup of Gnus and
each `g' takes about 15 seconds. I have all mails Gcc:'ed to nnfolder:
groups where about 50MB+ of mails are stored. Can this be the cause? Why it
is slower even on `g' (gnus-group-get-new-news)?
-- 
Pavel Janík

In the beginning was the word, and the word was content-type: text/plain.
                  -- Kilian A. Foth in comp.emacs.xemacs

Re: Typos...

[Andreas Jaeger]

Pavel@Janik.cz (Pavel Janík) writes:

>    From: Simon Josefsson <jas@extundo.com>
>    Date: Sat, 25 Aug 2001 22:03:36 +0200
>
> Hi,
>
>    > > Interactive use seems to be faster now but bootstrapping takes
>    > > ages...
>    > 
>    > It writes a few hundred bytes from memory to disk per group, that
>    > shouldn't hardly be noticable unless you have a very slow network file
>    > system or something.  Maybe something after the bootstrapping is
>    > taking time, and the bootstrapping message is still in the minibuffer?
>
> I also tried the new code - bootstrapping is a pain. It took about a minute
> on my machine (Celeron 550/128MB/~40 nnfolder groups). Startup of Gnus and
> each `g' takes about 15 seconds. I have all mails Gcc:'ed to nnfolder:
> groups where about 50MB+ of mails are stored. Can this be the cause? Why it
> is slower even on `g' (gnus-group-get-new-news)?

That's the same problem I notice.  'g' takes long.  I do have a number
of nnfolder groups and access them via NFS.  One has a size of 60 MB
and each 'g' seems to look at this file.  This might have been a
bootstrap problem (my partition was full) and since then I reverted to
an older gnus version.  Simon, does this make sense?  I'll try again
the newer version when I have time to wait for bootstrapping/'g',

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Typos...

[Simon Josefsson]

Andreas Jaeger <aj@suse.de> writes:

>> I also tried the new code - bootstrapping is a pain. It took about a minute
>> on my machine (Celeron 550/128MB/~40 nnfolder groups). Startup of Gnus and
>> each `g' takes about 15 seconds. I have all mails Gcc:'ed to nnfolder:
>> groups where about 50MB+ of mails are stored. Can this be the cause? Why it
>> is slower even on `g' (gnus-group-get-new-news)?
>
> That's the same problem I notice.  'g' takes long.  I do have a number
> of nnfolder groups and access them via NFS.  One has a size of 60 MB
> and each 'g' seems to look at this file.  This might have been a
> bootstrap problem (my partition was full) and since then I reverted to
> an older gnus version.  Simon, does this make sense?  I'll try again
> the newer version when I have time to wait for bootstrapping/'g',

Yeah, currently `g' makes nnfolder/nnml read the mark files and
calculate things, which isn't necessary (it's only necessary if the
marks file is changed).  I'll fix it soon.

However, the bootstrapping should be quick.  It is just writing from
memory to disk.  Shouldn't take a minute.  Please do M-x
elp-instrument-package RET nnfolder RET, delete *.mrk, re-start Gnus
and report what M-x elp-results RET says.

Re: Typos...

[Pavel Janík]

   From: Simon Josefsson <jas@extundo.com>
   Date: Sun, 26 Aug 2001 17:06:37 +0200

Hi Simon,

   > Yeah, currently `g' makes nnfolder/nnml read the mark files and
   > calculate things, which isn't necessary (it's only necessary if the
   > marks file is changed).  I'll fix it soon.

just to demonstrate the behavior from the users side: my Emacs just after
booting takes about 14M of memory:

pavel    19923 28.4  8.6 13928 10932 ?       S    21:49   0:02 emacs -i

Just after gnus-unplugged it took about 80M:

pavel    19923 35.3 45.2 81340 57496 ?       S    21:49   0:15 emacs -i
-- 
Pavel Janík

The problem here is that there is parent and child but no adult.
                  -- Lynne Jolitz about Unix and Unix hackers

Re: Typos...

[Daniel Pittman]

On Sun, 26 Aug 2001, Simon Josefsson wrote:

[...]

> Yeah, currently `g' makes nnfolder/nnml read the mark files and
> calculate things, which isn't necessary (it's only necessary if the
> marks file is changed).  I'll fix it soon.

Oh, good. I was starting to ponder instrumenting Gnus and finding out
where it was wasting time on startup; it takes a few tens of seconds
(with no progress message even at verbosity 7 -- hint) to do the marks
stuff over my 1.1GB of nnml...

        Daniel

-- 
I keep my head above the surface, trying to breath, looking for land.
I keep an eye at the distant horizon waiting for help, clutching the sky.
        -- Covenant, _Phoenix_

Re: Typos...

[Simon Josefsson]

Daniel Pittman <daniel@rimspace.net> writes:

>> Yeah, currently `g' makes nnfolder/nnml read the mark files and
>> calculate things, which isn't necessary (it's only necessary if the
>> marks file is changed).  I'll fix it soon.
>
> Oh, good. I was starting to ponder instrumenting Gnus and finding out
> where it was wasting time on startup; it takes a few tens of seconds
> (with no progress message even at verbosity 7 -- hint) to do the marks
> stuff over my 1.1GB of nnml...

I've added some more messages.  I did not made the optimization I
thought of before yet, as it would actually be useful if you could
instrument Gnus to find out where it's spending time, it may suggest
other functions to optimize.

Please M-x elp-instrument-package RET gnus RET and M-x
elp-instrument-package RET nn RET.  M-x elp-results RET after starting
Gnus and after doing `g' would be useful.  Thanks.

Profiling Gnus (was: Re: Typos...)

[Daniel Pittman]

On Mon, 27 Aug 2001, Simon Josefsson wrote:
> Daniel Pittman <daniel@rimspace.net> writes:
> 
>>> Yeah, currently `g' makes nnfolder/nnml read the mark files and
>>> calculate things, which isn't necessary (it's only necessary if the
>>> marks file is changed).  I'll fix it soon.
>>
>> Oh, good. I was starting to ponder instrumenting Gnus and finding out
>> where it was wasting time on startup; it takes a few tens of seconds
>> (with no progress message even at verbosity 7 -- hint) to do the
>> marks stuff over my 1.1GB of nnml...
> 
> I've added some more messages.  I did not made the optimization I
> thought of before yet, as it would actually be useful if you could
> instrument Gnus to find out where it's spending time, it may suggest
> other functions to optimize.

Well, I am happy enough to do this...

> Please M-x elp-instrument-package RET gnus RET and M-x
> elp-instrument-package RET nn RET.  M-x elp-results RET after starting
> Gnus and after doing `g' would be useful.  Thanks.

...if you will let me in on the secret of getting it to instrument the
functions. :)

I updated to the latest CVS version and removed all the compiled lisp
from gnus/lisp. So far, so good.

So, I can't actually `elp-instrument-package' gnus because it's full of
autoload functions. Fine. I restart, use dired and %m, L all the .el is
the Gnus directory...

...which still has a bunch of autoloads hanging around and now won't
actually start.

*sigh*

So, if anyone can tell me how to do this profiling, I am quite happy to
do so.

        Daniel

-- 
In addition to my other numerous acquaintances, I have one more intimate
confidant. My depression is the most faithful mistress I have known ---
no wonder, then, that I return the love.
        -- Søren Kierkegaard, _Either/Or_ (1843)

Re: Profiling Gnus (was: Re: Typos...)

[Lars Magne Ingebrigtsen]

Daniel Pittman <daniel@rimspace.net> writes:

> So, I can't actually `elp-instrument-package' gnus because it's full of
> autoload functions. Fine. I restart, use dired and %m, L all the .el is
> the Gnus directory...
>
> ...which still has a bunch of autoloads hanging around and now won't
> actually start.

There should be no problem profiling autoloaded functions.  Do you
have an old version of elp in your load path?  It used to have
problems with autoload (before I fixed it :-).

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Profiling Gnus (was: Re: Typos...)

[Daniel Pittman]

On Tue, 28 Aug 2001, Lars Magne Ingebrigtsen wrote:
> Daniel Pittman <daniel@rimspace.net> writes:
> 
>> So, I can't actually `elp-instrument-package' gnus because it's full
>> of autoload functions. Fine. I restart, use dired and %m, L all the
>> .el is the Gnus directory...
>>
>> ...which still has a bunch of autoloads hanging around and now won't
>> actually start.
> 
> There should be no problem profiling autoloaded functions.  Do you
> have an old version of elp in your load path?  It used to have
> problems with autoload (before I fixed it :-).

Alas. I have the version that ships with the current XEmacs 21.5 branch,
listing itself as:

;; Version:       2.37

Soooo... does this mean that I should add "update the XEmacs ELP
version" to my list of things to do?

If so, would y'all be so kind as to suggest where I might get the most
recent version of the ELP from, I will have a look at it. :)

        Daniel

*sigh*

-- 
The sexual revolution is over and the microbes won.
        -- P. J. O'Rourke, _Give war a chance_ (1992)

Re: Profiling Gnus (was: Re: Typos...)

[Simon Josefsson]

Daniel Pittman <daniel@rimspace.net> writes:

>> Please M-x elp-instrument-package RET gnus RET and M-x
>> elp-instrument-package RET nn RET.  M-x elp-results RET after starting
>> Gnus and after doing `g' would be useful.  Thanks.
>
> ...if you will let me in on the secret of getting it to instrument the
> functions. :)
>
> I updated to the latest CVS version and removed all the compiled lisp
> from gnus/lisp. So far, so good.
>
> So, I can't actually `elp-instrument-package' gnus because it's full of
> autoload functions. Fine. I restart, use dired and %m, L all the .el is
> the Gnus directory...
>
> ...which still has a bunch of autoloads hanging around and now won't
> actually start.
>
> *sigh*
>
> So, if anyone can tell me how to do this profiling, I am quite happy to
> do so.

Perhaps elp is broken in XEmacs.

Ok, try evaluating

(mapcar (lambda (file) (and (string-match ".el$" file) (load-library file)))
        (directory-files "~/gnus/lisp"))

before you do the above.  Any better?

Re: Profiling Gnus (was: Re: Typos...)

[Daniel Pittman]

On Tue, 28 Aug 2001, Simon Josefsson wrote:
> Daniel Pittman <daniel@rimspace.net> writes:

[...]

> Perhaps elp is broken in XEmacs.

I am betting or LMI's offer of "outdated version", myself. It works fine
for anything that isn't an autoload function.

> Ok, try evaluating
> 
> (mapcar (lambda (file) (and (string-match ".el$" file) (load-library
> file))) (directory-files "~/gnus/lisp"))
> 
> before you do the above.  Any better?

Actually, unless this differs substantially from doing this through the
dired interface (%m el$ RET L), it didn't help. It loaded the toolbar
stuff, which then threw errors as Gnus started.

So, no results yet. If I get a new version of ELP some time soon I will
post the results, though. You have not been forgotten. :)

        Daniel

-- 
Art is moral passion married to entertainment. Moral passion
without entertainment is propaganda, and entertainment without
moral passion is television.
        -- Rita Mae Brown

Re: Profiling Gnus (was: Re: Typos...)

[Simon Josefsson]

Daniel Pittman <daniel@rimspace.net> writes:

>> Ok, try evaluating
>> 
>> (mapcar (lambda (file) (and (string-match ".el$" file) (load-library
>> file))) (directory-files "~/gnus/lisp"))
>> 
>> before you do the above.  Any better?
>
> Actually, unless this differs substantially from doing this through the
> dired interface (%m el$ RET L), it didn't help. It loaded the toolbar
> stuff, which then threw errors as Gnus started.

Toolbar stuff?  Did you get a backtrace?

Re: Typos...

[Simon Josefsson]

Andreas Jaeger <aj@suse.de> writes:

>> I also tried the new code - bootstrapping is a pain. It took about a minute
>> on my machine (Celeron 550/128MB/~40 nnfolder groups). Startup of Gnus and
>> each `g' takes about 15 seconds. I have all mails Gcc:'ed to nnfolder:
>> groups where about 50MB+ of mails are stored. Can this be the cause? Why it
>> is slower even on `g' (gnus-group-get-new-news)?
>
> That's the same problem I notice.  'g' takes long.  I do have a number
> of nnfolder groups and access them via NFS.  One has a size of 60 MB
> and each 'g' seems to look at this file.  This might have been a
> bootstrap problem (my partition was full) and since then I reverted to
> an older gnus version.  Simon, does this make sense?  I'll try again
> the newer version when I have time to wait for bootstrapping/'g',

Is it fast, err, less slow now?

Re: Typos...

[Pavel Janík]

   From: Simon Josefsson <jas@extundo.com>
   Date: Mon, 27 Aug 2001 18:21:39 +0200

Hi Simon,

   > > an older gnus version.  Simon, does this make sense?  I'll try again
   > > the newer version when I have time to wait for bootstrapping/'g',
   > 
   > Is it fast, err, less slow now?

now, it's *really* fast! Thank you.
-- 
Pavel Janík

panic("esp_handle: current_SC == penguin within interrupt!");
                  -- 2.2.16 drivers/scsi/esp.c

Re: Typos...

[Andreas Jaeger]

Simon Josefsson <jas@extundo.com> writes:

> Andreas Jaeger <aj@suse.de> writes:
>
>>> I also tried the new code - bootstrapping is a pain. It took about a minute
>>> on my machine (Celeron 550/128MB/~40 nnfolder groups). Startup of Gnus and
>>> each `g' takes about 15 seconds. I have all mails Gcc:'ed to nnfolder:
>>> groups where about 50MB+ of mails are stored. Can this be the cause? Why it
>>> is slower even on `g' (gnus-group-get-new-news)?
>>
>> That's the same problem I notice.  'g' takes long.  I do have a number
>> of nnfolder groups and access them via NFS.  One has a size of 60 MB
>> and each 'g' seems to look at this file.  This might have been a
>> bootstrap problem (my partition was full) and since then I reverted to
>> an older gnus version.  Simon, does this make sense?  I'll try again
>> the newer version when I have time to wait for bootstrapping/'g',
>
> Is it fast, err, less slow now?

It's ok now ;-)

I just see every time I press 'g' now the following message in the
minibuffer flying along - even if nothing has changed at all:

Checking new news...done
Updating marks for mail.x86-64.announce...
Updating marks for mail.libstdc++...
Updating marks for mail.linux-future...
Updating marks for mail.netdev...
...

Is it really necessary to update the marks every time?

It's fast - but annoying,

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Typos...

[Simon Josefsson]

Andreas Jaeger <aj@suse.de> writes:

> I just see every time I press 'g' now the following message in the
> minibuffer flying along - even if nothing has changed at all:
>
> Checking new news...done
> Updating marks for mail.x86-64.announce...
> Updating marks for mail.libstdc++...
> Updating marks for mail.linux-future...
> Updating marks for mail.netdev...
> ...
>
> Is it really necessary to update the marks every time?

No, they are gone now.  (Unless you frob `gnus-verbose'.)