Re: What makes set-window-buffer slow?

["Clément Pit--Claudel" <clement.pit@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3270 bytes --]

On 2016-06-25 03:30, Eli Zaretskii wrote:
>> Cc: acm@muc.de, schwab@suse.de, emacs-devel@gnu.org
>> From: Clément Pit--Claudel <clement.pit@gmail.com>
>> Date: Fri, 24 Jun 2016 17:33:23 -0400
>>
>> When started, Proof General splits the screen in two:
>>
>> |             |             |
>> |             |             |
>> | User's file | Message log |
>> |             |             |
>> |             |             |
>>
>> Each time a message is received, it's displayed in the Message log window.
>> My extension sometimes reuses that window for other things (for example, to show company-mode's documentation buffer).
>> The set-window-buffer call is there to ensure that the user sees new messages. Of course in most cases that call is useless: that's why predicating it on the window not already displaying the message log makes things faster.
> 
> Does the WINDOW argument of set-window-buffer name the selected window
> at the time of the call?  If not, set-window-buffer will cause all the
> other windows to be redisplayed, so arranging for WINDOW to be the
> selected window might speed up things.

The window was indeed not selected at the time of the call. Would a simple with-selected-window around the call do it? If so, could set-window-buffer just do that? Btw, do you think there is any issue with just not calling set-window-buffer if the window already contains that buffer?

> Another potential speedup might be had if you invoke set-window-buffer
> with its KEEP-MARGINS argument non-nil.

Interesting, thanks! That wouldn't prevent the scrollbar's length from being adjusted to the length of the newly displayed buffer, right?

> Alternatively, try changing your hook to use its own window for
> whatever you want to show, leaving the "Message Log" window alone.

I don't think that's possible, unfortunately :/

> I'm puzzled how come redisplay was called so many times (2400) in this
> scenario.  Is such a large number reasonable?  How many seconds did it
> take to run the scenario?

5 to 8 minutes, I think. (Btw, maybe the profiler could record this timing information?

>>> Also, how come it doesn't happen on your machine?  Are any
>>> customizations involved?  Is your OS different from that of the other
>>> user?
>>
>> Somewhat unclear. The OS are the same (Linux mint), and the problem does happen in emacs -Q for the other user. The version of Emacs is the same.
> 
> How about local vs remote invocation, and/or the X configuration in
> general?

I think local invocation in both cases. Mate desktop vs. Cinnamon. Would it be useful for me to profile the same code on my own machine? Maybe comparing the profiles would help.

> Also, what about toolkits and Cairo -- did both builds use the same
> optional features in this department?

I think so; I use the default build setting, plus a patch to revert a commit that makes Emacs unusable for me since April 2014.

> Finally, if the user can try a later Emacs, it might help, because
> some non-trivial redisplay optimizations were done since 24.4.

Ok, I'll keep this in mind; I don't think that will happen for them until Debian updates, though. And in any case, I don't even have this problem on 24.4...

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]