Re: Long lines and bidi

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 08 Feb 2013 16:07:23 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Profile alone is not enough.  Please tell how did you "scroll",
> exactly (which commands did you use), and please also show the
> absolute times it took to perform each command.

Btw, if you are serious about finding a solution to the long-line
display misfeature (or any other too-slow redisplay situation), I
generally find it necessary to do precision timing of the suspicious
parts of code, because otherwise it is impossible to find the actual
culprits.  On GNU/Linux, I use the following simple function:

  double
  timer_time (void)
  {
    struct timeval tv;

    gettimeofday (&tv, NULL);
    return tv.tv_usec * 0.000001 + tv.tv_sec;
  }

Now, to time a particular portion of the code, do something like this:

  double t1, t2;
  ...
  t1 = timer_time ();
  /* here comes the code that should be timed */
  t2 = timer_time ();
  if (t2 - t1 > THRESHOLD)
    fprintf (stderr, "that code took %.4g sec\n", t2 - t1);

The value of THRESHOLD depends on the magnitude of the slow-down you
are working on.  I generally start with 0.1 of the time it takes to
perform some redisplay operation; e.g., if it takes 5 sec to move the
cursor, start with 0.5 sec.  gettimeofday has a sufficient resolution
on GNU/Linux to get you sub-millisecond accuracy, which is more than
enough for display engine measurements.

Using the above, you can quickly identify the function(s) that take
most of the time of a particular redisplay operation, then time the
parts of those functions to find the most expensive parts, and so on,
recursively, until you find the hot spots (more than 50% of the slow
operation).