I did a couple of tests, and stuff that involves a lot of set-c[ad]ring seems to happen 3-4 times as fast. Nice!
;All tests done using "racket -i -f as.scm", Racket v5.0
;Where x is (n-of 1000000 (rand))
;With mpairs
arc> (time:no:sort < x)
time: 12408 msec.
nil
;Normal arc3.1
arc> (time:no:sort < x)
time: 36004 msec.
nil
;This function destructively reverses a list, as in CL
; but it's actually slower than 'rev, for some reason
(def nreverse (xs)
(and xs
(let tail nil
(while xs
(let rest cdr.xs
(= cdr.xs tail
tail xs
xs rest)))
tail)))
;With mpairs
arc> (time:no:zap nreverse x)
time: 719 msec.
nil
;Normal arc3.1
arc> (time:no:zap nreverse x)
time: 2732 msec.
nil
On the other hand, it seems to slow down normal list operations somewhat, about 20%.
;The format of the output of "time" is "time: nnn msec."
; so we will take the output of a bunch of iterations,
; read all sexprs, and take the second of every three.
;With mpairs
arc> (map cadr (tuples (readall:tostring (repeat 30 (time:len x))) 3))
(66 65 63 63 62 62 62 63 66 63 63 69 74 66 63 371 97 92 74 71
71 71 64 71 63 71 63 63 63 63)
;With normal arc3.1
arc> (map cadr (tuples (readall:tostring (repeat 30 (time:len x))) 3))
(62 62 61 52 52 52 52 52 52 51 51 51 57 52 52 56 56 61 61 52 52
52 52 54 56 61 52 52 54 61)
On the whole, probably worth it.
And, by the way, for your amusement and my pleasure, I have a dinky little version of mergesort that runs 20% faster than the destructive version defined in arc.arc runs in arc3.1. It's stable, too. http://pastebin.com/XFz6T9xW
