[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Intelligent stacking of messages in the echo area
From: |
Ihor Radchenko |
Subject: |
Re: Intelligent stacking of messages in the echo area |
Date: |
Wed, 25 Dec 2019 01:32:27 +0800 |
> Are you sure this is not due to the code that you wrote (and didn't
> show)? IOW, if you change the window configuration, and then display
> something, shouldn't you expect a thorough redisplay?
Let me show some benchmarks with emacs -Q:
<the code from multi-message.el> ;C-x C-e
(setq nomulti nil) ; C-x C-e
(setq multi nil) ; C-x C-e
(let ((start (float-time)))
(setq set-message-function 'set-multi-message)
(dotimes (i 8) (message "foo %s" i) (split-window-below) (split-window-below)
(message "foo2") (delete-other-windows))
(setq multi-message-list nil)
(push (- (float-time) start) multi)
(car multi)) ; C-x C-e several times.
;; I can clearly see flickering (redrawing) of
;; emacs frame every time the mini-buffer is resized
(let ((start (float-time)))
(setq set-message-function nil)
(dotimes (i 8) (message "foo %s" i) (split-window-below) (split-window-below)
(message "foo2") (delete-other-windows))
(setq multi-message-list nil)
(push (- (float-time) start) nomulti)
(car nomulti)) ; C-x C-e several times
;; No redrawing is happening
(message "Without multi-message: %s sec\nWith multi-message: %s sec"
(/ (seq-reduce #'+ nomulti 0) (seq-length nomulti))
(/ (seq-reduce #'+ multi 0) (seq-length nomulti)))
Without multi-message: 0.009443044662475586 sec
With multi-message: 0.03390545646349589 sec
The difference is more that 3 times. With an actual heavy-duty emacs
config the difference is a lot more noticeable.
Best regards,
Ihor
Eli Zaretskii <address@hidden> writes:
>> From: Ihor Radchenko <address@hidden>
>> Date: Tue, 24 Dec 2019 17:40:18 +0800
>> Cc: ndame <address@hidden>, "address@hidden" <address@hidden>
>>
>> When I run a command changing current buffer and emitting multiple
>> messages, emacs frame is redrawn every time a new message comes out.
>> Specifically, I was running org-capture, which changes windows
>> configuration, switches to different buffer, and emits multiple messages
>> while running. Normally, it runs very fast (the capture template I used
>> does not require any user input), but with multi-message, I can see the
>> frame being redrawn on every new message popping up. Since window
>> configuration is different, full redraw is forced and the whole
>> org-capture runs a lot slower.
>
> Are you sure this is not due to the code that you wrote (and didn't
> show)? IOW, if you change the window configuration, and then display
> something, shouldn't you expect a thorough redisplay?
--
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong
University, Xi'an, China
Email: address@hidden, address@hidden