From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Newsgroups: gmane.emacs.bugs Subject: bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014). Date: Fri, 10 Jul 2015 09:55:18 -0700 Message-ID: <559FF8F6.2060209@live.com> References: <559F9FAF.8090708@live.com> <83egkgb2wo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KOjoN4BBGrK03O9hK35ou08vLRKBHxP13" X-Trace: ger.gmane.org 1436547384 14523 80.91.229.3 (10 Jul 2015 16:56:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jul 2015 16:56:24 +0000 (UTC) Cc: 21028@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 10 18:56:13 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 1ZDbau-0006vU-1x for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jul 2015 18:56:12 +0200 Original-Received: from localhost ([::1]:45470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDbat-00015W-HK for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jul 2015 12:56:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDban-00015Q-Oe for bug-gnu-emacs@gnu.org; Fri, 10 Jul 2015 12:56:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDbak-0005hd-H8 for bug-gnu-emacs@gnu.org; Fri, 10 Jul 2015 12:56:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDbak-0005hZ-E5 for bug-gnu-emacs@gnu.org; Fri, 10 Jul 2015 12:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZDbaj-0007O6-UF for bug-gnu-emacs@gnu.org; Fri, 10 Jul 2015 12:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Jul 2015 16:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21028 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21028-submit@debbugs.gnu.org id=B21028.143654733428364 (code B ref 21028); Fri, 10 Jul 2015 16:56:01 +0000 Original-Received: (at 21028) by debbugs.gnu.org; 10 Jul 2015 16:55:34 +0000 Original-Received: from localhost ([127.0.0.1]:46375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZDbaH-0007NO-IR for submit@debbugs.gnu.org; Fri, 10 Jul 2015 12:55:34 -0400 Original-Received: from mout.kundenserver.de ([212.227.17.24]:63338) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZDbaD-0007N7-Ub for 21028@debbugs.gnu.org; Fri, 10 Jul 2015 12:55:31 -0400 Original-Received: from [172.20.14.53] ([12.10.78.5]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0MbsGc-1ZTUXU0HOo-00JLXV; Fri, 10 Jul 2015 18:55:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <83egkgb2wo.fsf@gnu.org> X-Provags-ID: V03:K0:inwCrgWfXoFNkLxvGZjGk1vKhADKX48o2p2tx4bfL0E+dHgn0Rq qsHhLEwIsvVOiN+OCEVSBoRwfrI2RJ5DfHx527TN7hud/fOeDkBxS6kXrXQN5AKrll2g/PM 1FKBSCIXb6Wn5Y36YQ49thEyXY4rB+3X3ii4foyfSE23QHveTRVZayLkMWqYvnpwGgFCb43 3zdXgfN9Z/VOfMc6FORog== X-UI-Out-Filterresults: notjunk:1;V01:K0:pWss/HpARpw=:eZ6UU9gSCrBSC+dB/Dty78 zYQOgwVnQG2Yp+eBDy3kQjru1C/PeEL3q/HJSX6fKcdG4FS53STv+faOAyfARUCtO5n54Q0kD zdB59NyUpFYve3wrYV0aGnfGt3N091B5msITbLY453Yj3IsGwVF8V1qMG+Q0Hvl44BylWAeOA iuYawF85kk5SJKSyQTSOn4gOaO1IAbYYn+fQYS6hWTktUIETb/ke9rXqYusrpekVjEaShZSr2 Re5hkhCw7CCXdbCDhE0bh236hFuJT4ltU6IE8xvttmHEgxdNZhLPCyxq8a86YyqGdAtgFyUNp F/xNr5AX6cttNO3+OOZBoHQIcrr74DcTX3B58TrHs3AfF8QloBcj7W+7Zh7fU0vg1hSgjBKve gy4mi0fFAbW8GPW9UyfxuNx8DRYmOItJDyqEyzA5YWUrHcYsJzbbUK5RAXk0E65TjbAnGdfez Rm5Hj4rMYHCwah5EeVcRca/VNe3BA95v2Vp5zRXb0Bs57EumBEYbNz1p4SzNGFGOnSuKHXtkW MXfHpNyjkJtSxx7jVhVIbmpBNzajEItlJcCnr/ObSG+0KE493xoQqHqjWPSsB/RZxfzRAdebG X0G0ONTIvnzxNj8qC5nE4VMimQJksxm7FPMLtdocYIrm8KA8/MuqeEPCi5r3Dn5/x82E1LqOe kdLYfuTO9BKjJ1CY20D/GPP0b 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:104894 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KOjoN4BBGrK03O9hK35ou08vLRKBHxP13 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/10/2015 05:41 AM, Eli Zaretskii wrote: >> Date: Fri, 10 Jul 2015 03:34:23 -0700 >> From: Cl=C3=A9ment Pit--Claudel >> >> I tried to pinpoint the commit that introduced the bug, and found revi= sion af1a69f4d17a482c359d98c00ef86fac835b5fac by bisecting between 24.3 a= nd master. Here's the commit in question: >> >> af1a69f4d17a482c359d98c00ef86fac835b5fac is the first bad commit >> commit af1a69f4d17a482c359d98c00ef86fac835b5fac >> Author: Dmitry Antipov >> Date: Wed Apr 2 17:24:19 2014 +0400 >> >> * font.c (font_list_entities): Do not add empty vector to font c= ache. >> (font_matching_entity): Likewise. If matching entity is found, = insert >> 1-item vector with this entity instead of entity itself (Bug#171= 25). >=20 > Maybe I'm blind, but I don't see anything in that changeset that could > explain a performance hit. The modified code seems to do > approximately the same amount of work, and create the same data > structures, as the original one. Are you sure that backing out those > changes fixes your problem? Thanks for looking into this. Yes, reverting these changes on master fixe= s the problem. I ran a number of experiments: * I timed the sample code that I sent, before and after af1a69f4d17a482c3= 59d98c00ef86fac835b5fac: ** On af1a69f4d17a482c359d98c00ef86fac835b5fac (the commit that I identif= ied as bad): $ time src/emacs -Q --eval "(progn (dotimes (_ 3) (set-fontset-font t = 'unicode (font-spec :name \"Arial\") nil 'append)) (redisplay t) (kill-em= acs))" real 0m2.249s user 0m1.259s sys 0m0.100s $ time src/emacs -Q --eval "(progn (dotimes (_ 3) (set-fontset-font t = 'unicode (font-spec :name \"Arial\") nil 'append)) (dotimes (_ 50) (inser= t \"=E6=97=A5=E6=9C=AC=E5=9B=BD\n\")) (redisplay t) (kill-emacs))" real 0m5.749s user 0m2.717s sys 0m0.857s ** On 200c532bd04a67a89db602462d74706051c61178 (the previous commit) $ time src/emacs -Q --eval "(progn (dotimes (_ 3) (set-fontset-font t = 'unicode (font-spec :name \"Arial\") nil 'append)) (redisplay t) (kill-em= acs))" real 0m2.214s user 0m1.247s sys 0m0.077s $ time src/emacs -Q --eval "(progn (dotimes (_ 3) (set-fontset-font t = 'unicode (font-spec :name \"Arial\") nil 'append)) (dotimes (_ 50) (inser= t \"=E6=97=A5=E6=9C=AC=E5=9B=BD\n\")) (redisplay t) (kill-emacs))" real 0m2.226s user 0m1.222s sys 0m0.106s Thus the operation of inserting these 50 lines takes about 3.5 seconds on= the bad commit, while it's instantaneous in the previous commit. * On master, timed the same code before and after reverting af1a69f4d17a4= 82c359d98c00ef86fac835b5fac: ** Before reverting $ time emacs -Q --eval "(progn (dotimes (_ 3) (set-fontset-font t 'uni= code (font-spec :name \"Arial\") nil 'append)) (redisplay t) (kill-emacs)= )" real 0m2.441s user 0m1.363s sys 0m0.142s $ time emacs -Q --eval "(progn (dotimes (_ 3) (set-fontset-font t 'uni= code (font-spec :name \"Arial\") nil 'append)) (dotimes (_ 50) (insert \"= =E6=97=A5=E6=9C=AC=E5=9B=BD\n\")) (redisplay t) (kill-emacs))" real 0m5.149s user 0m2.569s sys 0m0.742s ** After reverting $ time src/emacs -Q --eval "(progn (dotimes (_ 3) (set-fontset-font t = 'unicode (font-spec :name \"Arial\") nil 'append)) (redisplay t) (kill-em= acs))" real 0m2.413s user 0m1.351s sys 0m0.147s $ time src/emacs -Q --eval "(progn (dotimes (_ 3) (set-fontset-font t = 'unicode (font-spec :name \"Arial\") nil 'append)) (dotimes (_ 50) (inser= t \"=E6=97=A5=E6=9C=AC=E5=9B=BD\n\")) (redisplay t) (kill-emacs))" real 0m2.570s user 0m1.608s sys 0m0.083s The figures are very similar to the tests above: with that patch insertin= g 50 lines takes 3 seconds, and without it it's instantaneous. Thus I thi= nk it's safe to say that this particular patch is indeed responsible for = the performance regression. But maybe I'm missing something? Cheers, Cl=C3=A9ment. --KOjoN4BBGrK03O9hK35ou08vLRKBHxP13 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVn/j3AAoJEPqg+cTm90wjBugQAJLUiW9pQUNiBvqvb+HOMyeN gdJg3iyFU4PQwvdebsmn7QGZZKzaO3+Ja49wETCvX5ndd2331wPAYu71YfRJJwEg jkIXCzOSj2zWEZy8lHGoJwH3JtLs1mk1FUWk18oiq+gmSvPA+yz4/7nDYPhMJhlI Bh/lBUHq81yh5LTMCtRyetFwuvZdzNfuRbSmIwoOSH0JXmLvv3fPW/pUXCFp5YtF 14hsR4ZZcacG1NTcqWyIeYHVcryIEwQwt4vLVMHgEPGSu+keH0a6X+rbbc4qxtc3 aEvFLVSvXZ7N/PKNwMkej2v3gETy0syi0D9ZepbHCfLhHf/oxmyDSdp1jsqz8o8S VlmNkkZ9FkQwXHZxzVAU1NrN/SKAFAiTVfUEyVA+RVdBYfqVMX/e4YtOlE2IIJ7T znQ4JIzc+i4UdsusdvJWQTbF/RY0zTSB5Ixtgsj8Ed0EBrcE4uwdgGNFJMYu/CtI kUc2HocCk16vCZ7o1Crtk6lpI+LsZ/TMd0FoKZ61JU6vxVUT0rGA7mRBZpHNIedz okfSJIq6wNSiNj6uVRzzDa+DuiIFUgRjCPtyTWc2/Rzt6accLHdsBoO5p5klEn1s rNHgZDeuI7N/7O5Lj5Qt0RoVb8LQyF2p+mvwgCbg5MEeaqGD6HkHStveU70b4jEo zeQ8OOwxSn460PhPZdyR =aFBr -----END PGP SIGNATURE----- --KOjoN4BBGrK03O9hK35ou08vLRKBHxP13--