From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.bugs Subject: bug#20887: 'make bootstrap' now verrrry slow due to recent isearch changes Date: Thu, 25 Jun 2015 18:32:51 +0100 Message-ID: References: <558A0950.2000501@cs.ucla.edu> <2nbng5pou7.fsf@fencepost.gnu.org> <558AB250.5040908@cs.ucla.edu> <83vbeddu4d.fsf@gnu.org> <83si9hdthc.fsf@gnu.org> <83mvzoex5g.fsf@gnu.org> <838ub7eso2.fsf@gnu.org> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1435253605 5670 80.91.229.3 (25 Jun 2015 17:33:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 17:33:25 +0000 (UTC) Cc: 20887@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 25 19:33:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Z8B1W-0001GT-Nk for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Jun 2015 19:33:14 +0200 Original-Received: from localhost ([::1]:56802 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8B1W-0007JB-51 for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Jun 2015 13:33:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8B1R-0007HJ-2K for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2015 13:33:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8B1M-0001CK-UT for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2015 13:33:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8B1M-0001CF-SB for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2015 13:33:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z8B1L-00020K-Uy for bug-gnu-emacs@gnu.org; Thu, 25 Jun 2015 13:33:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Artur Malabarba Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Jun 2015 17:33:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20887 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20887-submit@debbugs.gnu.org id=B20887.14352535827700 (code B ref 20887); Thu, 25 Jun 2015 17:33:03 +0000 Original-Received: (at 20887) by debbugs.gnu.org; 25 Jun 2015 17:33:02 +0000 Original-Received: from localhost ([127.0.0.1]:57435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z8B1I-000204-KR for submit@debbugs.gnu.org; Thu, 25 Jun 2015 13:33:01 -0400 Original-Received: from mail-lb0-f172.google.com ([209.85.217.172]:33002) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z8B1G-0001zo-18 for 20887@debbugs.gnu.org; Thu, 25 Jun 2015 13:32:58 -0400 Original-Received: by lbbvz5 with SMTP id vz5so49928707lbb.0 for <20887@debbugs.gnu.org>; Thu, 25 Jun 2015 10:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=010lBZbQa6DfTlgtVUzqOKj/i+B7WNqG2OdQeY1cNdI=; b=Za7P70vor5Wci2rRkPVR9w6M0aCpIFNM4RnrNxYmD6FEXoxE2TMm/3AwLCgyd4Bckb 9nrtsgjhFUBatIBCjOC1KHj0Q7K61YmF2H/X7H7lmKyCR2q5t3G4MQptrZSGW+WOj3rH FtBk5th3mRORI/MYslyGZv6RfwAfrOGn7SK7iTCiXjsnGBsy36HNKL0+AvjlBFButrk9 a29VcKST0oDw8aRDAR5XrhlWtT2iAM6kKlX44xFGoGC9VcbiJHsAzkb8rZAMvE8KaQjA RZaIz/aMZKQFjReHKjOH/XpJ6rhfCOKqS2PtGCot6yr4RM1d/TC1SbLl6EO8aP6zpMMC dU7Q== X-Received: by 10.112.25.69 with SMTP id a5mr45496564lbg.16.1435253571937; Thu, 25 Jun 2015 10:32:51 -0700 (PDT) Original-Received: by 10.25.214.133 with HTTP; Thu, 25 Jun 2015 10:32:51 -0700 (PDT) In-Reply-To: <838ub7eso2.fsf@gnu.org> X-Google-Sender-Auth: nCyvrhEaW53kuQfWp7HSU1PKu6Y X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:104346 Archived-At: > However, I think the version you pushed can be further improved. For > starters, you don't need to populate the table first, and only then > use it; you can produce the property value for a character and use it > in the same call to map-char-table. For example, the following > snippet loops only once over the table, and does its job in about 2 > sec: > > (let* ((table (unicode-property-table-internal 'decomposition)) > (func (char-table-extra-slot table 1))) > (map-char-table > (lambda (key val) > (if (consp key) > (message "%s %s" key (funcall func (car key) val table)) > (message "%s %s" key (funcall func key val table)))) > table)) > > All you need is replace the silly 'message' calls with the body of > your processing code (and handle all the characters in a range of > codepoints, not just the first one). The "handle all characters in a range" part is the issue. For me, the first time that snippet is run it calls the lambda a total of 101 times (and barely takes an instant). More importantly, every single time the key is a range, and the value returned by the `funcall' is actually the decomposition of the *first* char in that range (not the full range). For instance, one of the messages I get from your snippet is: (64256 . 64383) (compat 102 102) But if you call (get-char-code-property 64257 'decomposition) (note the 7) you'll get a decomposition of (compat 102 105). Maybe I'm missing some simplification here. I'm aware I could run a loop inside the lambda going from (car key) to (cdr key), and then do the `(funcall func ...)' on each item in the range, but I fail to see how that would be faster than running a second map-char-table. In fact, the number of steps involved is much larger if you loop: - the current version has a map of 100 steps and another of 5721, - your proposal would have a map of 100 steps, each containing a loop of about 120 steps, which totals to over 12000 steps (I counted). Again, maybe I'm missing something, or maybe looping would be much faster than that second `map-char-table', but it seems to me like it would just be doing more work. > Your code also calls unicode-property-table-internal twice, and the > above method will solve that as well. Yes, that was an oversight. My intention was to reuse the `table' var. I'll fix that.