From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/27870 Path: main.gmane.org!not-for-mail From: Hrvoje Niksic Newsgroups: gmane.emacs.gnus.general Subject: Re: Brian May's `Re: Bugs in PGnus' article jams Gnus Date: 07 Dec 1999 17:16:42 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: <9t9g0xeafpx.fsf@mraz.iskon.hr> References: <877liqx43y.fsf@senstation.vvf.fi> <87n1rmvnkq.fsf@senstation.vvf.fi> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035164817 26791 80.91.224.250 (21 Oct 2002 01:46:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:46:57 +0000 (UTC) Return-Path: Original-Received: from bart.math.uh.edu (bart.math.uh.edu [129.7.128.48]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id LAA05059 for ; Tue, 7 Dec 1999 11:17:23 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by bart.math.uh.edu (8.9.1/8.9.1) with ESMTP id KAB19355; Tue, 7 Dec 1999 10:17:16 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 07 Dec 1999 10:17:26 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id KAA20398 for ; Tue, 7 Dec 1999 10:17:11 -0600 (CST) Original-Received: from mraz.iskon.hr (root@mraz.iskon.hr [195.29.170.8]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id LAA05038 for ; Tue, 7 Dec 1999 11:16:46 -0500 (EST) Original-Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id RAA13403; Tue, 7 Dec 1999 17:16:43 +0100 X-Authentication-Warning: mraz.iskon.hr: hniksic set sender to hniksic@iskon.hr using -f Original-To: ding@gnus.org X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h writes: > Laura Conrad 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.