From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: ido-switch-buffer is slow with many buffers; others are fast Date: Sat, 14 Nov 2020 19:19:27 -0500 Message-ID: <875z67mpyo.fsf@catern.com> References: <87ima7nbic.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17618"; mail-complaints-to="usenet@ciao.gmane.io" To: Dmitry Gutov , catern@catern.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 15 01:20:10 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ke5m5-0004SJ-Ud for ged-emacs-devel@m.gmane-mx.org; Sun, 15 Nov 2020 01:20:09 +0100 Original-Received: from localhost ([::1]:52268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ke5m5-0007LG-0J for ged-emacs-devel@m.gmane-mx.org; Sat, 14 Nov 2020 19:20:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ke5lT-0006uZ-TX for emacs-devel@gnu.org; Sat, 14 Nov 2020 19:19:31 -0500 Original-Received: from venus.catern.com ([68.183.49.163]:45060) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ke5lR-00006l-GI for emacs-devel@gnu.org; Sat, 14 Nov 2020 19:19:31 -0500 Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=98.7.229.235; helo=localhost; envelope-from=sbaugh@catern.com; receiver= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=catern.com; s=mail; t=1605399568; bh=GrfEo75Bg1FHrMR4RtbhwsVkFCr2iVbMXbh3gG6r0rg=; h=From:To:Subject:In-Reply-To:References:Date; b=L1l4KGvwwAnvp5nOS4r91/Bf83GhAR7JbV7+Y1lcCiCiCLVyjniyyM7SRdZyY2v3V /WJO4k+fXo5aIkd+kVy5oUaremRVcrX/VoUVhmLisoJ/yhHp9bmANF9R+z3TjHY1RB jfhdQs3M5SZB3KCKympS76QqVAhPgU+gHA+S0D8M= Original-Received: from localhost (cpe-98-7-229-235.nyc.res.rr.com [98.7.229.235]) by venus.catern.com (Postfix) with ESMTPSA id 0B6F72DC36D; Sun, 15 Nov 2020 00:19:27 +0000 (UTC) In-Reply-To: Received-SPF: pass client-ip=68.183.49.163; envelope-from=sbaugh@catern.com; helo=venus.catern.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/14 19:19:28 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259188 Archived-At: Dmitry Gutov writes: > On 14.11.2020 18:34, catern@catern.com wrote: >> I recently became annoyed enough in my 1000-buffer Emacs instance to >> start profiling things. >> >> I was disappointed to find that the buffer-switching slowness I'd seen >> is the fault of ido-switch-buffer. >> >> ido-switch-buffer takes over a second before it starts accepting user >> input, with this many buffers. > > Which Emacs version are you using? > > A fix that seems relevant has been added in df4991093b9 recently. But > it's only in Emacs 28 thus far. Oh, indeed, that seems perfect! So, forget everything I said before - this fixes ido's performance to be quite fine with large numbers of buffers. So that specific problem is solved. The associated bug#41029 mentions: >Many of the buffer locals (in particular I think it's the >SYMBOL_FORWARDED types --- my terminoly may be off), appear to be O(n) >to bind, where n is the number of live buffers. That's quite worrying - that implies that pretty much any code will run slower as the number of buffers increases, even if it doesn't have anything to do with buffers! This explains the slow performance of let-binding case-fold-search that I mentioned in another branch of this thread. Is this poor scaling of binding buffer locals a known problem? Has anyone worked on fixing this?