GNU bug report logs - #12463
24.2; pos-visible-in-window-p gets slower over time

Previous Next

Full log

Message #14 received at 12463 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jörg Walter <jwalt <at> garni.ch>
Cc: 12463 <at> debbugs.gnu.org
Subject: Re: bug#12463: 24.2; pos-visible-in-window-p gets slower over time
Date: Tue, 18 Sep 2012 13:23:30 +0300

> From: Jörg Walter <jwalt <at> garni.ch>
> Date: Tue, 18 Sep 2012 11:46:13 +0200
> 
> > Jörg, does this happen with earlier versions of Emacs, like 24.1 or
> > 23.3?
> 
> I've done some additional tests: It does *not* happen with Ubuntu's emacs23 
> (23.3.1). Just for cross-checking, I ran Win32 emacs 24.2 once via wine and 
> once in VirtualBox+WinXP, in both cases no bug.
> 
> It *does* happen with Ubuntu's emacs24 (24.1.1), which is where I first noticed 
> 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 = timer_time ();
    /* Some code being timed.  */
    t2 = timer_time ();
    if (t2 - t1 >= 0.001)  /* show time from 1 msec and up */
      {
	fprintf (stderr, "foo took %.4g sec\n", t2 - t1);
	fflush (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 same
timings, then the code which implements pos-visible-in-window-p is not
the issue, and we should look elsewhere for the explanations.

Also, if you repeat the benchmark after terminating it, do the numbers
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.