From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.help Subject: Re: Too long completion delay time in LISP interaction mode. Date: Wed, 20 Oct 2021 07:49:40 +0200 Message-ID: <87pms0s0ex.fsf@gnu.org> References: <87tuhcs2ov.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17053"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.0; emacs 29.0.50 Cc: help-gnu-emacs@gnu.org To: Hongyi Zhao Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 20 07:58:46 2021 Return-path: Envelope-to: geh-help-gnu-emacs@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 1md4cf-0004HT-Ky for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 20 Oct 2021 07:58:45 +0200 Original-Received: from localhost ([::1]:51200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1md4cd-0004nJ-Tc for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 20 Oct 2021 01:58:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1md4c1-0004nA-Sv for help-gnu-emacs@gnu.org; Wed, 20 Oct 2021 01:58:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54110) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1md4c0-0007AD-P2; Wed, 20 Oct 2021 01:58:05 -0400 Original-Received: from auth1-smtp.messagingengine.com ([66.111.4.227]:53343) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1md4bz-0004g8-AX; Wed, 20 Oct 2021 01:58:04 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 9AA4227C0054; Wed, 20 Oct 2021 01:58:01 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 20 Oct 2021 01:58:01 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvfedgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfhgfhffvufffjgfkgggtgfesthhqredttderjeenucfhrhhomhepvfgrshhs ihhlohcujfhorhhnuceothhsughhsehgnhhurdhorhhgqeenucggtffrrghtthgvrhhnpe eiudfghffhjeevvedvhfffgeetleeljefffeeggfeugeegleehfeeiueejhfehgeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhorhhnod hmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdekieejfeekjeekgedqieefhedv leekqdhtshguhheppehgnhhurdhorhhgsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Oct 2021 01:58:00 -0400 (EDT) In-reply-to: X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:133903 Archived-At: Hongyi Zhao writes: >> First, I'd try to isolate where the slowdown happens. The >> screenshots suggests you are using company-mode with custom hacks to >> get the numbering of candidates and you are using some fuzzy >> completion-style. >> >> So I'd start with emacs -Q and typing (map in *scratch* to get >> the *Completions* buffer. That will probably be fast but deliver >> less results because of the default value of `completion-styles'. >> Then I'd try out your settings of `completion-styles' (and > > `C-h o completion-styles RET' > > completion-styles is a variable defined in =E2=80=98minibuffer.el=E2=80= =99. > > Its value is (hotfuzz) Never heard of it. But is it a suitable catch-all completion style, i.e., suitable for using it without another more prefix-oriented style preceeding it? FWIW, when I type "(map", I'm most probably not interested in having smartparens-mode, or lsp:document-symbol-capabilities-hierarchical-document-symbol-support? showing up as the top candidates but more in mapcar, mapc, mapcan, you name it... >> Also, using the profiler might shed some light on where the time is >> spent, see (info "(elisp) Profiling"). > > `M-x profiler-start RET cpu and mem RET' I think you only need cpu here. > Typeset (map) in scratch buffer, and then > > `M-x profiler-report RET', gives the following results: > > 262,542,852 87% - command-execute > 262,542,852 87% - funcall-interactively > 262,538,196 87% - counsel-M-x > 262,538,196 87% - let > 262,355,940 87% - ivy-read > 262,355,940 87% - apply > 262,354,884 87% + # > 182,256 0% + counsel--M-x-externs So the bottleneck is in the lambda which you didn't expand. But I'm also not sure if you are profiling the right thing because I don't think that in-buffer completion (in terms of `completion-at-point-functions') starts with M-x (or counsel-M-x). Bye, Tassilo