From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12463: 24.2; pos-visible-in-window-p gets slower over time Date: Tue, 18 Sep 2012 13:23:30 +0300 Message-ID: <83fw6f1vfh.fsf@gnu.org> References: <87wqzs1a4c.fsf@queen.i-did-not-set--mail-host-address--so-tickle-me> <83mx0n22p0.fsf@gnu.org> <5511358.p8J1TLefsG@queen> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1347963897 19766 80.91.229.3 (18 Sep 2012 10:24:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Sep 2012 10:24:57 +0000 (UTC) Cc: 12463@debbugs.gnu.org To: =?UTF-8?Q?J=C3=B6rg?= Walter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 18 12:24:59 2012 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 1TDuzC-000412-QG for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Sep 2012 12:24:59 +0200 Original-Received: from localhost ([::1]:46470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDuz8-0004AQ-JX for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Sep 2012 06:24:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDuz3-0004AD-Fx for bug-gnu-emacs@gnu.org; Tue, 18 Sep 2012 06:24:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDuyx-00026D-5O for bug-gnu-emacs@gnu.org; Tue, 18 Sep 2012 06:24:49 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDuyx-000268-1v for bug-gnu-emacs@gnu.org; Tue, 18 Sep 2012 06:24:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TDv0E-0008En-3q for bug-gnu-emacs@gnu.org; Tue, 18 Sep 2012 06:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Sep 2012 10:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12463 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12463-submit@debbugs.gnu.org id=B12463.134796391531615 (code B ref 12463); Tue, 18 Sep 2012 10:26:02 +0000 Original-Received: (at 12463) by debbugs.gnu.org; 18 Sep 2012 10:25:15 +0000 Original-Received: from localhost ([127.0.0.1]:40956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDuzT-0008Dq-7Y for submit@debbugs.gnu.org; Tue, 18 Sep 2012 06:25:15 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:34067) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDuzQ-0008Di-7f for 12463@debbugs.gnu.org; Tue, 18 Sep 2012 06:25:13 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MAJ00F00JIGWS00@a-mtaout22.012.net.il> for 12463@debbugs.gnu.org; Tue, 18 Sep 2012 13:23:21 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAJ00FWTJIWWO00@a-mtaout22.012.net.il>; Tue, 18 Sep 2012 13:23:21 +0300 (IDT) In-reply-to: <5511358.p8J1TLefsG@queen> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:64547 Archived-At: > From: J=F6rg Walter > Date: Tue, 18 Sep 2012 11:46:13 +0200 >=20 > > J=F6rg, does this happen with earlier versions of Emacs, like 24.= 1 or > > 23.3? >=20 > I've done some additional tests: It does *not* happen with Ubuntu's= emacs23=20 > (23.3.1). Just for cross-checking, I ran Win32 emacs 24.2 once via = wine and=20 > once in VirtualBox+WinXP, in both cases no bug. >=20 > It *does* happen with Ubuntu's emacs24 (24.1.1), which is where I f= irst noticed=20 > the problem. It also happens on all X toolkits (gtk, gtk3, athena,= lucid). Thanks. Would it be possible for you to time the related code on the C level, and find which part(s) are responsible for the slow-down? To do that, insert into the C code calls to a function that returns some measure of time before and after the code fragment being timed, and print the difference between two successive calls if that difference exceeds some threshold. For example: double timer_time (void) { struct timeval tv; gettimeofday (&tv, NULL); return tv.tv_usec * 0.000001 + tv.tv_sec; } [...] double t1, t2; extern double timer_time (void); [...] t1 =3D timer_time (); /* Some code being timed. */ t2 =3D timer_time (); if (t2 - t1 >=3D 0.001) /* show time from 1 msec and up */ { =09fprintf (stderr, "foo took %.4g sec\n", t2 - t1); =09fflush (stderr); } The code in question is Fpos_visible_in_window_p itself, and its main subroutine, pos_visible_p. The latter is a large function, so if it is the culprit, successively dividing it into smaller pieces by bisection will allow you to show what part is taking the most time. If you can do the above, the first thing to establish is whether timing the whole of Fpos_visible_in_window_p on the C level shows approximately the same times and exhibits the same growth trend as what 'benchmark' shows on the Lisp level. If it doesn't show the sam= e timings, then the code which implements pos-visible-in-window-p is no= t the issue, and we should look elsewhere for the explanations. Also, if you repeat the benchmark after terminating it, do the number= s start from the last (longest) measurement or from the first (shortest), or somewhere in between? IOW, do you need to restart Emacs to reset the measurements back to the first shortest value? Thanks.