* Re: Byte-compiling the line specs [not found] ` <199510311413.PAA06470@ssv4.dina.kvl.dk> @ 1995-11-01 16:34 ` Ken Raeburn 1995-11-01 20:39 ` Felix Lee 0 siblings, 1 reply; 5+ messages in thread From: Ken Raeburn @ 1995-11-01 16:34 UTC (permalink / raw) 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.... ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Byte-compiling the line specs 1995-11-01 16:34 ` Byte-compiling the line specs Ken Raeburn @ 1995-11-01 20:39 ` Felix Lee 1995-11-02 21:38 ` Ken Raeburn 0 siblings, 1 reply; 5+ messages in thread From: Felix Lee @ 1995-11-01 20:39 UTC (permalink / raw) 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)) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Byte-compiling the line specs 1995-11-01 20:39 ` Felix Lee @ 1995-11-02 21:38 ` Ken Raeburn 1995-11-03 1:26 ` Felix Lee 0 siblings, 1 reply; 5+ messages in thread From: Ken Raeburn @ 1995-11-02 21:38 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Byte-compiling the line specs 1995-11-02 21:38 ` Ken Raeburn @ 1995-11-03 1:26 ` Felix Lee 1995-11-06 13:32 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 5+ messages in thread From: Felix Lee @ 1995-11-03 1:26 UTC (permalink / raw) 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. -- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Byte-compiling the line specs 1995-11-03 1:26 ` Felix Lee @ 1995-11-06 13:32 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 5+ messages in thread From: Lars Magne Ingebrigtsen @ 1995-11-06 13:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1995-11-06 13:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <199510311028.LAA06365@ssv4.dina.kvl.dk> [not found] ` <199510311052.CAA16806@desiree.teleport.com> [not found] ` <199510311413.PAA06470@ssv4.dina.kvl.dk> 1995-11-01 16:34 ` Byte-compiling the line specs Ken Raeburn 1995-11-01 20:39 ` Felix Lee 1995-11-02 21:38 ` Ken Raeburn 1995-11-03 1:26 ` Felix Lee 1995-11-06 13:32 ` Lars Magne Ingebrigtsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).