From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: fix for bug 10994 breaks ido customizations in major way Date: Sun, 05 May 2013 15:38:25 +0200 Message-ID: <87mws9sg1a.fsf@wanadoo.es> References: <87ip2zm89w.fsf@wanadoo.es> <87vc6xsnhb.fsf@wanadoo.es> <87r4hlsjnj.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1367761115 17190 80.91.229.3 (5 May 2013 13:38:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 May 2013 13:38:35 +0000 (UTC) Cc: Le Wang , emacs-devel@gnu.org To: Leo Liu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 05 15:38:34 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYz97-0003SZ-TL for ged-emacs-devel@m.gmane.org; Sun, 05 May 2013 15:38:34 +0200 Original-Received: from localhost ([::1]:51243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYz97-0007pW-Hk for ged-emacs-devel@m.gmane.org; Sun, 05 May 2013 09:38:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYz94-0007pF-AJ for emacs-devel@gnu.org; Sun, 05 May 2013 09:38:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYz93-00011J-AS for emacs-devel@gnu.org; Sun, 05 May 2013 09:38:30 -0400 Original-Received: from impaqm1.telefonica.net ([213.4.138.17]:55960 helo=telefonica.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYz92-00010p-W2 for emacs-devel@gnu.org; Sun, 05 May 2013 09:38:29 -0400 Original-Received: from IMPmailhost6.adm.correo ([10.20.102.127]) by IMPaqm1.telefonica.net with bizsmtp id YCHb1l00N2kvMAa3MDeRgG; Sun, 05 May 2013 15:38:25 +0200 Original-Received: from qcore ([83.40.116.149]) by IMPmailhost6.adm.correo with BIZ IMP id YDeQ1l00Q3DUQuj1mDeRPd; Sun, 05 May 2013 15:38:25 +0200 X-CMAE-Analysis: v=1.1 cv=3vSug+m9oYZW2lLZaIW/sb4etgpD20hWvawC9j4AjWo= c=1 sm=1 a=DQlLCnKHR5QA:10 a=jB3pZ5H4rBYA:10 a=IkcTkHD0fZMA:10 a=sSE9TqpJnXXWdi4WNHITQg==:17 a=pGLkceISAAAA:8 a=Fl_y7hHX3aaNWslX-YAA:9 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=sSE9TqpJnXXWdi4WNHITQg==:117 X-original-sender: 981711563@telefonica.net In-Reply-To: (Leo Liu's message of "Sun, 05 May 2013 20:58:26 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 213.4.138.17 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159335 Archived-At: Leo Liu writes: > On 2013-05-05 20:20 +0800, =C3=93scar Fuentes wrote: >> Starting with 10000 candidates, ido flex matching enabled and flx >> disabled, I see no responsiveness degradation while randomly typing >> chars. > > In my emacs -q, eval the following: > > (let ((choices)) > (mapatoms (lambda (a) > (when (or (boundp a) (fboundp a)) > (push (symbol-name a) choices)))) > (benchmark-run 10 (delete-dups choices))) > > gives me: (19.909896999999997 0 0.0) > > So on average there is 2 seconds delay in a MacBook with 2.0G x 2 CPU. > > CHOICES is 10321 long in my case. I ran your test code on my Emacs session and the result was (126.326822296 0 0.0) being `choices' 26959 items long, which is fairly consistent with your observations and with the O(n^2) complexity of delete-dups. However, executing ido-completing-read with a list of 10530 strings (without duplicates and on a CPU that seems to be similar to yours on performance) takes 0.72 seconds, which is way faster than the 2 seconds you observe for the list of symbols of similar size. So it seems that delete-dups is faster for strings than symbols. I agree that using delete-dups is not the ideal solution due to performance concerns, but the current state breaks a quite convenient usage pattern (i.e. use text properties for carrying extra information about candidates) on a way that renders the machine to its knees. IMHO incurring a performance penalty on huge lists is well worth the pain in this case.