GNU bug report logs - #65251
30.0.50; Duration in compilation buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 65251 in the body.
You can then email your comments to 65251 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Duration in compilation buffer
Date: Sat, 12 Aug 2023 20:30:51 +0200

[Message part 1 (text/plain, inline)]

In the *compilation* buffer, we see timestamps when the compilation
started and finished.  It would be nice to also see how long the
compilation command took.  The attached patch does that.  It looks like
this:

  Compilation finished at Sat Aug 12 20:23:57, 2.52s

Helmut

[0001-When-a-compilation-finishes-show-how-long-it-took.patch (text/x-diff, inline)]

From d6bdf293287a5f252de0cf2dd00cfeaff1c02f80 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut <at> gmail.com>
Date: Sat, 12 Aug 2023 19:17:43 +0200
Subject: [PATCH] When a compilation finishes, show how long it took

Insert the duration, not just the timestamp.

* lisp/progmodes/compile.el (compilation--start-time): New variable.
(compilation-start): Set it.
(compilation-handle-exit): Use it to compute the duration and
 insert it in human readable form.
---
 lisp/progmodes/compile.el | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 6d151db8a83..276c9a5d3e1 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1862,6 +1862,9 @@ compilation-insert-annotation
     (apply #'insert args)
     (put-text-property start (point) 'compilation-annotation t)))
 
+;; The time when the compilation started.
+(defvar compilation--start-time nil)
+
 ;;;###autoload
 (defun compilation-start (command &optional mode name-function highlight-regexp
                                   continue)
@@ -1993,6 +1996,7 @@ compilation-start
                  mode-name
 		 (substring (current-time-string) 0 19))
 	 command "\n")
+        (setq-local compilation--start-time (current-time))
 	(setq thisdir default-directory))
       (set-buffer-modified-p nil))
     ;; Pop up the compilation buffer.
@@ -2480,7 +2484,15 @@ compilation-handle-exit
 	(message "%s" (cdr status)))
     (if (bolp)
 	(forward-char -1))
-    (compilation-insert-annotation " at " (substring (current-time-string) 0 19))
+    (compilation-insert-annotation
+     " at "
+     (substring (current-time-string) 0 19)
+     ", "
+     (let* ((secs (float-time (time-since compilation--start-time))))
+       (cond ((< secs 1) (format "%.0fms" (* secs 1000)))
+	     ((< secs 10) (format "%.2fs" secs))
+	     ((< secs 60) (format "%.1fs" secs))
+	     (t (format-seconds "%hh%mm%z%ss" secs)))))
     (goto-char (point-max))
     ;; Prevent that message from being recognized as a compilation error.
     (add-text-properties omax (point)
-- 
2.39.2

Message #8 received at 65251 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: eller.helmut <at> gmail.com
Cc: 65251 <at> debbugs.gnu.org
Subject: bug#65251: 30.0.50; Duration in compilation buffer
Date: Wed, 16 Aug 2023 21:15:45 +0200

> In the *compilation* buffer, we see timestamps when the compilation
> started and finished.  It would be nice to also see how long the
> compilation command took.

Not a bad idea.
 
> +;; The time when the compilation started.
> +(defvar compilation--start-time nil)

What about using defvar-local? Then...

> +        (setq-local compilation--start-time (current-time))

can use plain setq. And if you use (float-time) here, then... 

> +     (let* ((secs (float-time (time-since compilation--start-time))))

...this becomes a simple subtraction: (- (float-time) compilation--start-time)

> +       (cond ((< secs 1) (format "%.0fms" (* secs 1000)))
> +	     ((< secs 10) (format "%.2fs" secs))
> +	     ((< secs 60) (format "%.1fs" secs))
> +	     (t (format-seconds "%hh%mm%z%ss" secs)))))

First of all, proper style is to separate the number and unit by a space.
The 'ms' case isn't very important -- 745 ms is no more readable than 0.745 s, probably less so.
The last case is also less than readable. Something like 3:45:58 would be better.

The reader would also like to know what this new time indication means. What about

   ..., duration 34.5 s

or

   ..., 34.5 s elapsed

?

Message #11 received at 65251 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 65251 <at> debbugs.gnu.org
Subject: Re: bug#65251: 30.0.50; Duration in compilation buffer
Date: Thu, 17 Aug 2023 00:36:52 +0200

On Wed, Aug 16 2023, Mattias Engdegård wrote:

>> +;; The time when the compilation started.
>> +(defvar compilation--start-time nil)
>
> What about using defvar-local? Then...
>
>> +        (setq-local compilation--start-time (current-time))
>
> can use plain setq.

Seems to be a matter of taste.  I don't know what the Official Style
Guide says about it.

> And if you use (float-time) here, then... 
>
>> +     (let* ((secs (float-time (time-since compilation--start-time))))
>
> ...this becomes a simple subtraction: (- (float-time) compilation--start-time)
>

But then we couldn't use bignums.  And representing time values as a
pair of bignums is cool.  So cool that it was worth to require libgmp
for Emacs.  Oh wait, current-time still doesn't use bignums.  But when
it switches, it will be sooo cool.

Anyway, ERT uses current-time for ert--stats-start-time and I followed
that example.

>> +       (cond ((< secs 1) (format "%.0fms" (* secs 1000)))
>> +	     ((< secs 10) (format "%.2fs" secs))
>> +	     ((< secs 60) (format "%.1fs" secs))
>> +	     (t (format-seconds "%hh%mm%z%ss" secs)))))
>
> First of all, proper style is to separate the number and unit by a space.
> The 'ms' case isn't very important -- 745 ms is no more readable than
> 0.745 s, probably less so.
> The last case is also less than readable. Something like 3:45:58 would
> be better.

Seems to be a matter of taste.  I copied the style used by Go's Duration
type: https://pkg.go.dev/time#Duration.String

> The reader would also like to know what this new time indication
> means. What about
>
>    ..., duration 34.5 s
>
> or
>
>    ..., 34.5 s elapsed
>
> ?

Seems to be a matter of taste.  ERT prints it like

Ran 10 tests, 10 results as expected, 0 unexpected (2023-08-17 00:29:48+0200, 0.813428 sec) 

and nobody seems to complain.

Helmut

Message #14 received at 65251 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: mattias.engdegard <at> gmail.com, 65251 <at> debbugs.gnu.org
Subject: Re: bug#65251: 30.0.50; Duration in compilation buffer
Date: Thu, 17 Aug 2023 08:33:19 +0300

> Cc: 65251 <at> debbugs.gnu.org
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Thu, 17 Aug 2023 00:36:52 +0200
> 
> On Wed, Aug 16 2023, Mattias Engdegård wrote:
> 
> >> +;; The time when the compilation started.
> >> +(defvar compilation--start-time nil)
> >
> > What about using defvar-local? Then...
> >
> >> +        (setq-local compilation--start-time (current-time))
> >
> > can use plain setq.
> 
> Seems to be a matter of taste.  I don't know what the Official Style
> Guide says about it.
> 
> > And if you use (float-time) here, then... 
> >
> >> +     (let* ((secs (float-time (time-since compilation--start-time))))
> >
> > ...this becomes a simple subtraction: (- (float-time) compilation--start-time)
> >
> 
> But then we couldn't use bignums.  And representing time values as a
> pair of bignums is cool.  So cool that it was worth to require libgmp
> for Emacs.  Oh wait, current-time still doesn't use bignums.  But when
> it switches, it will be sooo cool.
> 
> Anyway, ERT uses current-time for ert--stats-start-time and I followed
> that example.
> 
> >> +       (cond ((< secs 1) (format "%.0fms" (* secs 1000)))
> >> +	     ((< secs 10) (format "%.2fs" secs))
> >> +	     ((< secs 60) (format "%.1fs" secs))
> >> +	     (t (format-seconds "%hh%mm%z%ss" secs)))))
> >
> > First of all, proper style is to separate the number and unit by a space.
> > The 'ms' case isn't very important -- 745 ms is no more readable than
> > 0.745 s, probably less so.
> > The last case is also less than readable. Something like 3:45:58 would
> > be better.
> 
> Seems to be a matter of taste.  I copied the style used by Go's Duration
> type: https://pkg.go.dev/time#Duration.String
> 
> > The reader would also like to know what this new time indication
> > means. What about
> >
> >    ..., duration 34.5 s
> >
> > or
> >
> >    ..., 34.5 s elapsed
> >
> > ?
> 
> Seems to be a matter of taste.  ERT prints it like
> 
> Ran 10 tests, 10 results as expected, 0 unexpected (2023-08-17 00:29:48+0200, 0.813428 sec) 
> 
> and nobody seems to complain.

It sounds like you reject all of Mattias's comments?  That's somewhat
unusual around here.  Does that above mean that you insist on
submitting your original patch with no further changes, or will you be
sending an updated patch?

Message #17 received at 65251 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattias.engdegard <at> gmail.com, 65251 <at> debbugs.gnu.org
Subject: Re: bug#65251: 30.0.50; Duration in compilation buffer
Date: Thu, 17 Aug 2023 07:55:37 +0200

On Thu, Aug 17 2023, Eli Zaretskii wrote:

> It sounds like you reject all of Mattias's comments?  That's somewhat
> unusual around here.  Does that above mean that you insist on
> submitting your original patch with no further changes, or will you be
> sending an updated patch?

I can submit an updated patch, if it is wanted.  But it didn't sound
like that me.  I can also continue using compilation-finish-functions in
my .emacs, if that's easier for you.

Helmut

Message #20 received at 65251 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: mattias.engdegard <at> gmail.com, 65251 <at> debbugs.gnu.org
Subject: Re: bug#65251: 30.0.50; Duration in compilation buffer
Date: Thu, 17 Aug 2023 09:05:19 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: mattias.engdegard <at> gmail.com,  65251 <at> debbugs.gnu.org
> Date: Thu, 17 Aug 2023 07:55:37 +0200
> 
> On Thu, Aug 17 2023, Eli Zaretskii wrote:
> 
> > It sounds like you reject all of Mattias's comments?  That's somewhat
> > unusual around here.  Does that above mean that you insist on
> > submitting your original patch with no further changes, or will you be
> > sending an updated patch?
> 
> I can submit an updated patch, if it is wanted.  But it didn't sound
> like that me.  I can also continue using compilation-finish-functions in
> my .emacs, if that's easier for you.

I intended to install this once there are no more review comments, as
I think this could be a useful addition.  I believe Mattias also
thought the idea was a good one.  So my preference is for you to post
an updated patch, yes.

TIA

Message #23 received at 65251 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattias.engdegard <at> gmail.com, 65251 <at> debbugs.gnu.org
Subject: Re: bug#65251: 30.0.50; Duration in compilation buffer
Date: Thu, 17 Aug 2023 20:48:22 +0200

[Message part 1 (text/plain, inline)]

On Thu, Aug 17 2023, Eli Zaretskii wrote:

> I intended to install this once there are no more review comments, as
> I think this could be a useful addition.  I believe Mattias also
> thought the idea was a good one.  So my preference is for you to post
> an updated patch, yes.

Here it is:

[0001-When-a-compilation-finishes-show-how-long-it-took.patch (text/x-diff, inline)]

From 3f41a75a61a08c1e2850bf3e3e4d1d2d137aeedd Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut <at> gmail.com>
Date: Thu, 17 Aug 2023 20:46:05 +0200
Subject: [PATCH] When a compilation finishes, show how long it took

Insert the duration, not just the timestamp.

* lisp/progmodes/compile.el (compilation--start-time): New variable.
(compilation-start): Set it.
(compilation-handle-exit): Use it to compute the duration and insert
it in human readable form.
---
 lisp/progmodes/compile.el | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 6d151db8a83..a41fca7de1e 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1862,6 +1862,9 @@ compilation-insert-annotation
     (apply #'insert args)
     (put-text-property start (point) 'compilation-annotation t)))
 
+;; The time when the compilation started as returned by `float-time'.
+(defvar-local compilation--start-time nil)
+
 ;;;###autoload
 (defun compilation-start (command &optional mode name-function highlight-regexp
                                   continue)
@@ -1993,6 +1996,7 @@ compilation-start
                  mode-name
 		 (substring (current-time-string) 0 19))
 	 command "\n")
+        (setq compilation--start-time (float-time))
 	(setq thisdir default-directory))
       (set-buffer-modified-p nil))
     ;; Pop up the compilation buffer.
@@ -2480,7 +2484,14 @@ compilation-handle-exit
 	(message "%s" (cdr status)))
     (if (bolp)
 	(forward-char -1))
-    (compilation-insert-annotation " at " (substring (current-time-string) 0 19))
+    (compilation-insert-annotation
+     " at "
+     (substring (current-time-string) 0 19)
+     ", duration "
+     (let* ((secs (- (float-time) compilation--start-time)))
+       (cond ((< secs 10) (format "%.2f s" secs))
+	     ((< secs 60) (format "%.1f s" secs))
+	     (t (format-seconds "%h:%m:%s" secs)))))
     (goto-char (point-max))
     ;; Prevent that message from being recognized as a compilation error.
     (add-text-properties omax (point)
-- 
2.39.2

Message #26 received at 65251 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 65251 <at> debbugs.gnu.org
Subject: Re: bug#65251: 30.0.50; Duration in compilation buffer
Date: Fri, 18 Aug 2023 14:06:44 +0200

17 aug. 2023 kl. 20.48 skrev Helmut Eller <eller.helmut <at> gmail.com>:

> Here it is:

Thank you! Pushed to master with some very slight editing, under my own name (but your credit) since you seemed reluctant about the changes -- hope that is all right.

(I think we prefer patches as attachments -- I had to edit it a bit to apply, which wasn't any trouble since the patch was so short.)

Further improvements are perfectly possible, but this is unquestionably an improvement.
Otherwise, if you aren't too unhappy about the resolution, the bug can be closed.

Message #29 received at 65251 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 65251 <at> debbugs.gnu.org
Subject: Re: bug#65251: 30.0.50; Duration in compilation buffer
Date: Fri, 18 Aug 2023 22:55:10 +0200

On Fri, Aug 18 2023, Mattias Engdegård wrote:

> Otherwise, if you aren't too unhappy about the resolution, the bug can
> be closed.

Yes, close it.

Helmut

Message #34 received at 65251-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: mattias.engdegard <at> gmail.com, 65251-done <at> debbugs.gnu.org
Subject: Re: bug#65251: 30.0.50; Duration in compilation buffer
Date: Sat, 19 Aug 2023 08:54:40 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  65251 <at> debbugs.gnu.org
> Date: Fri, 18 Aug 2023 22:55:10 +0200
> 
> On Fri, Aug 18 2023, Mattias Engdegård wrote:
> 
> > Otherwise, if you aren't too unhappy about the resolution, the bug can
> > be closed.
> 
> Yes, close it.

Thanks, done.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.