From: Eli Zaretskii <eliz@gnu.org>
To: Robert Pluim <rpluim@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
Date: Mon, 26 Mar 2018 20:28:15 +0300 [thread overview]
Message-ID: <837epyg30w.fsf@gnu.org> (raw)
In-Reply-To: <87k1ty22p1.fsf@gmail.com> (message from Robert Pluim on Mon, 26 Mar 2018 18:59:06 +0200)
> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 26 Mar 2018 18:59:06 +0200
> Cc: zhang cc <ccsmile2008@outlook.com>, Emacs developers <emacs-devel@gnu.org>
>
> Noam Postavsky <npostavs@gmail.com> writes:
>
> > On 26 March 2018 at 12:34, Robert Pluim <rpluim@gmail.com> wrote:
> >> Robert Pluim <rpluim@gmail.com> writes:
> >>
> >>> I get the same: 0.1 seconds under GTK, 0.000446348s under -nw
> >>
> >> And profiling pointed at window--maybe-raise-frame. Testing then
> >> pointed at make-frame-visible. Disabling the call to that in
> >> window--maybe-raise-frame makes the test virtually instantaneous for
> >> me. Looks like x_make_frame_visible is the culprit.
> >
> > Does changing x-wait-for-event-timeout affect this?
>
> Yes. 0.001990967s with that let-bound to nil. The time increases as I increase
> x-wait-for-event-timeout.
Right. Then I guess this is expected, and users who are annoyed by
the additional 100 msec on the one hand, and see no adverse effects
when it is nil OTOH, should do that, and be done.
IOW, the default is sub-optimal, but safe, and we couldn't find a
better solution at the time.
next prev parent reply other threads:[~2018-03-26 17:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-26 10:12 Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s) zhang cc
2018-03-26 15:16 ` Eli Zaretskii
2018-03-26 15:22 ` zhang cc
[not found] ` <544b8346-bda9-45eb-9573-1d51d9f768b2@Spark>
2018-03-26 15:25 ` zhang cc
2018-03-26 15:30 ` Eli Zaretskii
2018-03-26 16:09 ` Robert Pluim
2018-03-26 16:29 ` Clément Pit-Claudel
2018-03-26 16:34 ` Robert Pluim
2018-03-26 16:37 ` Noam Postavsky
2018-03-26 16:59 ` Robert Pluim
2018-03-26 17:28 ` Eli Zaretskii [this message]
2018-03-26 17:49 ` Stefan Monnier
2018-03-26 18:17 ` Eli Zaretskii
2018-03-26 18:26 ` Stefan Monnier
2018-03-26 18:33 ` Eli Zaretskii
2018-03-26 18:41 ` Stefan Monnier
2018-03-26 18:46 ` martin rudalics
2018-03-26 18:58 ` Eli Zaretskii
2018-03-26 19:16 ` martin rudalics
2018-03-26 19:24 ` Eli Zaretskii
2018-03-26 21:41 ` martin rudalics
2018-03-27 2:50 ` Eli Zaretskii
2018-03-27 7:23 ` martin rudalics
2018-03-29 9:37 ` Eli Zaretskii
2018-03-29 23:15 ` Noam Postavsky
2018-03-29 23:20 ` Noam Postavsky
2018-03-30 7:51 ` Eli Zaretskii
2018-03-26 20:09 ` Stefan Monnier
2018-03-26 21:42 ` martin rudalics
2018-03-27 2:45 ` Eli Zaretskii
2018-03-27 3:41 ` Stefan Monnier
2018-03-27 7:23 ` martin rudalics
2018-03-27 12:00 ` Stefan Monnier
2018-03-29 8:58 ` Eli Zaretskii
2018-03-26 18:46 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837epyg30w.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.