Re: Byte-compiling the line specs

Re: Byte-compiling the line specs

[Ken Raeburn]

   From: Per Abrahamsen <abraham@dina.kvl.dk>
   Date: Tue, 31 Oct 1995 15:13:59 +0100

   I get a bit more encouraging results with Emacs 19.29 and the
   following code:

   (let ((i 100000)
   ...


   Here is the timings:

			   Min     Max
   -----------------------------------------
   Empty Loop               5       6
   "99999"                  7       8
   princ                   13      14
   format                  19      20
   number-to-string        16      17

   The three first didn't generate any garbage, while the two last
   triggered a lot of garbage collections.

Did you byte-compile the loop?  If you're interested in comparing just the
formatting and insertion mechanisms, I think it's a good idea.

I tried it.  (Byte-compiled the file, read it into a buffer, moved to the
end, ran eval-current-buffer and then eval-last-sexp a couple of times, to
get three values.)  The princ test was faster than both number-to-string
and format by about a factor of 3 (though the numerous gc passes may have
been another factor contributing to getting different results from yours).
The number-to-string and format timings were closer than in your tests.

I also experimented with some elisp code for computing the character
values to insert, using % and / and adding to ?0, and using the "insert"
byte-code opcode.  That eliminated the garbage collection, but only saved
about 20% over number-to-string and format.

I think princ is probably the way to go, at least for numbers.  Numeric
fields padded to a specified width might be another matter, though....

Re: Byte-compiling the line specs

[Felix Lee]

I couldn't figure out what I did the first time, so I started over,
taking careful notes.

ignoring garbage collection, princ is faster up to about 5 arguments.
after that, (insert (format "")) is faster.  this is mostly because
princ requires a funcall.  if a bytecode for princ were added, princ
would probably always win.

on the other hand, princ doesn't generate garbage, so it's probably an
amortized win for up to I-don't-know-how-many arguments.

on the other other hand, realistic formats are somewhat complicated.
throw in something like "%5d", then the funcall costs increase.

(side note.  it looks like the insertN bytecode is only a marginal win
over N inserts)

here's my timings (emacs 19.29, i586-unknown-linux).  garbage
collection was effectively disabled for these runs.  the format is
	(code
	 iterations
	 (65536*sec sec msec))

;; null loop
((t)
 50000
 (0 0 212964))

;; (defun call-nil ())
(((call-nil))
 50000
 (0 0 819474))

;; (defun call-identity (x) x)
(((call-identity n))
 50000
 (0 1 19664))



;; basic insert
(((insert "99999"))
 50000
 (0 0 550920))

(((insert "a" "b"))
 50000
 (0 0 743891))

(((insert a b))
 50000
 (0 0 777184))

(((insert "a") (insert "b"))
 50000
 (0 0 766438))


;; insertN v. N inserts
(((insert "a" "b" "c" "d" "e" "f" "g" "h"))
 50000
 (0 1 882816))

(((insert "a") (insert "b") (insert "c") (insert "d")
  (insert "e") (insert "f") (insert "g") (insert "h"))
 50000
 (0 2 128370))


;; princ
(((princ 99999))
 50000
 (0 5 641750))

;; calling a function that calls princ.
(((call-princ 99999))
 50000
 (0 7 402069))

(((insert
   (number-to-string 99999)))
 50000
 (0 6 807297))


;; princ v. format comparisons.

(((princ 99999) (insert "a"))
 50000
 (0 6 484584))

(((format "%d%s" 99999 "a"))
 50000
 (0 7 557146))

(((insert (format "%d%s" 99999 "a")))
 50000
 (0 8 985531))


(((princ 99999) (insert "a") (princ 99999) (insert "b"))
 50000
 (0 12 156523))

(((format "%d%s%d%s" 99999 "a" 99999 "b"))
 50000
 (0 12 377714))

(((insert (format "%d%s%d%s" 99999 "a" 99999 "b")))
 50000
 (0 13 873505))


(((format "%d%s%d%s%d%s" 99999 "a" 99999 "b" 99999 "c"))
 5000
 (0 1 534841))

(((insert (format "%d%s%d%s%d%s" 99999 "a" 99999 "b" 99999 "c")))
 5000
 (0 1 669104))

(((princ 99999) (insert "a")
  (princ 99999) (insert "b")
  (princ 99999) (insert "c"))
 5000
 (0 1 792144))

Re: Byte-compiling the line specs

[Ken Raeburn]

   here's my timings (emacs 19.29, i586-unknown-linux).  garbage
   collection was effectively disabled for these runs.  the format is

If garbage collection is disabled, I don't think it accurately
reflects what we're likely to see using such code inside gnus.  And I
definitely don't think garbage collection should be disabled while
building the summary buffer; emacs gets big enough as it is when I
fire up gnus.

If you turn gc back on, with a decent amount of allocation done (say,
do it after you've gotten into the gnus Group buffer -- not a freshly
started emacs), does princ come out on top again?

Re: Byte-compiling the line specs

[Felix Lee]

Ken Raeburn:
> If you turn gc back on, with a decent amount of allocation done (say,
> do it after you've gotten into the gnus Group buffer -- not a freshly
> started emacs), does princ come out on top again?

well, I was going to write a function to monitor garbage production,
but I got distracted into trying to optimize the funcall code.

(conclusion: i486 architecture doesn't have enough registers.  I
managed to get about 10% speedup in funcalls mainly by taking the
fragment that handles subr calls and putting it in a separate
function, which is odd (since subr calls were also sped up).  my
current guess is there's too much register pressure in Ffuncall.)

so, umm, I'll try gc monitoring soon.  but really, the best test is to
write a full-blown format-string compiler and see how it performs in
live cases.
--

Re: Byte-compiling the line specs

[Lars Magne Ingebrigtsen]

Felix Lee <flee@teleport.com> writes:

> so, umm, I'll try gc monitoring soon.  but really, the best test is to
> write a full-blown format-string compiler and see how it performs in
> live cases.

Definitely.  These timings are interesting, but `(princ 99999)' isn't
a very realistic element resulting from a line spec.  There's lots of
"%5d"s (etc) but no "%d"s.  I'd be very interested in seeing timings
resulting from transforming:

(insert
 (progn
   (insert
    (format "%c%c%c%s " gnus-tmp-unread gnus-tmp-replied gnus-tmp-score-char gnus-tmp-indentation))
   (let
       ((b
	 (point)))
     (insert
      (format "%c%4d: %-20s%c" gnus-tmp-opening-bracket gnus-tmp-lines
	      (let*
		  ((val
		    (eval gnus-tmp-name))
		   (valstr
		    (if
			(numberp val)
			(int-to-string val)
		      val)))
		(if
		    (>
		     (length valstr)
		     20)
		    (substring valstr 0 20)
		  valstr))
	      gnus-tmp-closing-bracket))
     (put-text-property b
			(point)
			'mouse-face gnus-mouse-face))
   (insert
    (format " %s\n" gnus-tmp-subject-or-nil))))

-- 
Home is where the cat is.