[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What makes set-window-buffer slow?

From: Clément Pit--Claudel
Subject: Re: What makes set-window-buffer slow?
Date: Sat, 25 Jun 2016 10:07:11 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

On 2016-06-25 03:30, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden, address@hidden
>> From: Clément Pit--Claudel <address@hidden>
>> 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 

>>> 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 


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]