Re: Brian May's `Re: Bugs in PGnus' article jams Gnus

[Hrvoje Niksic <hniksic@iskon.hr>]

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

> Laura Conrad <lconrad@gamesville.com> writes:
> 
> > I decided to upgrade to xemacs 21.1.8 last night, so I have tried this 
> > message on both versions.  It seems to hang 20.4 indefinitely (longer
> > than I wanted to wait), while 21.1.8 does indeed display eventually
> > (also longer than I WANTED to wait).
> 
> 20.4 finished here (250MHz SPARC) after 96 seconds.
> 
> Tue Dec  7 16:53:02 MET 1999
> Tue Dec  7 16:54:38 MET 1999

Let's see what XEmacs (21.2) spent time doing:

    Function Name                         Ticks    %/Total   Call Count
    ==================================    =====    =======   ==========
    generate-new-buffer-name              2303     45.876    6369
    (in garbage collection)               1662     33.108    
    get-buffer-create                     248      4.940     6976
    kill-buffer                           139      2.769     5763
    re-search-forward                     111      2.211     20685
    string-match                          63       1.255     45878
    put-char-table                        59       1.175     1822
    byte-code                             58       1.155     14892
    expand-file-name                      46       0.916     6072
    ietf-drums-token-to-list              30       0.598     3642
    ...
    -------------------------------------------------------------------
    Total                                 5020     100.00


    One tick = 1 ms

So all the time was spent in generate-new-buffer-name.  How weird!

The message has about 600 parts (why it was created so is a different
anomaly.)  The mm code in turn created several hundreds of buffers,
all using generate-new-buffer-name.  The algorithm of
generate-new-buffer-name is:

  count = 1;
  while (1)
    {
      sprintf (number, "<%d>", ++count);
      gentemp = concat2 (name, build_string (number));
      if (!NILP (ignore))
        {
          tem = Fstring_equal (gentemp, ignore);
          if (!NILP (tem))
            return gentemp;
        }
      tem = Fget_buffer (gentemp);
      if (NILP (tem))
	return gentemp;
    }

So, the more buffers you create, the more time it takes.  For the
number of parts here, it corresponds to tens of thousands of passes
through the above loop: and each pass actually conses up a string!

I think that's the source of the immense slowness.  I'll try to fix
it.