Re: Intelligent stacking of messages in the echo area

[Ihor Radchenko <yantar92@gmail.com>]

> 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 <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@gmail.com>
>> Date: Tue, 24 Dec 2019 17:40:18 +0800
>> Cc: ndame <emacsuser@freemail.hu>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> 
>> 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: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg