separate Setq commands speed

[andkal]

Hello
Is there a difference in programs speed of the following two codes?

(setq var1 1 var2 2 var3 3 ..... var_n 100)

(setq var1 1) (setq var2 2) (setq var3 3) ..... (setq var_n 100)

[ronjonp]

I would guess not much speed difference but would have to test. Why would you need to set 100 variables though ?

(defun _a nil
  (setq	a 1
	b 2
	c 3
  )
)
(defun _b nil (setq a 1) (setq b 2) (setq c 3))
(defun _c nil (mapcar 'set '(a b c) '(1 2 3)))

(benchmark '(_a _b _c))
;;;
;;;Benchmarking .....................Elapsed milliseconds / relative speed for 262144 iteration(s):
;;;
;;;    _B.....1063 / 1.03 <fastest>
;;;    _C.....1078 / 1.01
;;;    _A.....1094 / 1.00 <slowest>

[doaiena]

(setq var1 1 var2 2 var3 3 ..... var_n 100)

 
This is around 20% faster.

Have in mind though, that the gain from such an optimization is negligible /probably 1-2s for a billion operations/. If i were optimizing AutoLisp code, i wouldn't even bother with such a thing.

[ronjonp]

---

@doaiena wrote:

(setq var1 1 var2 2 var3 3 ..... var_n 100)

 
This is around 20% faster.

Have in mind though, that the gain from such an optimization is negligible /probably 1-2s for a billion operations/. If i were optimizing AutoLisp code, i wouldn't even bother with such a thing.

---

How did you come up with a 20% speed difference? The bench above isn't even close to that.

[doaiena]

Just uncomment the part of the code you want to test. I consistently get a difference of around 20% on this.

(defun test ( / timeStart)
(setq timeStart (getvar "Millisecs"))

(repeat 10000000

;;;(setq a nil)
;;;(setq b nil)
;;;(setq c nil)
;;;(setq d nil)
;;;(setq e nil)
;;;(setq f nil)
;;;(setq g nil)
;;;(setq h nil)
;;;(setq i nil)
;;;(setq j nil)
;;;(setq k nil)
;;;(setq l nil)
;;;(setq m nil)
;;;(setq n nil)
;;;(setq o nil)
;;;(setq p nil)
;;;(setq q nil)
;;;(setq r nil)
;;;(setq s nil)
;;;(setq u nil)


;;;(setq a nil b nil c nil d nil e nil f nil g nil
;;;      h nil i nil j nil k nil l nil m nil n nil
;;;      o nil p nil q nil r nil s nil u nil)

);repeat

(/ (- (getvar "Millisecs") timeStart) 1000.0)
);defun

[andkal]

Hi
Its easier for me to operate with separate setq functions rather than combined becouse I can easily cut or copy one and paste into some other place in the code. But it came to my mind that combined setq function might be faster so I wondered if there is a difference in speed worth bothering at all. Computers are fast nowadays anyway...
The same with number of variables - I came to a conclusion that sometimes it may not be worth reducing it as much as possible (to no to burden memory to much) becouse sometimes it makes code harder to understand. But I understand that there may be different opinions on this matter.

[martti.halminen]

When timing Lisp behaviour, the results may change depending on where a garbage collection happens.

Here (test) is the separate-setq version, interpreted:

_$ (test)
48.375
_$ (test)
22.484
_$ (test)
20.672
_$ (test)
20.688
_$ (test)
20.641

(test2) is the chained-setq version, interpreted:

_$ (test2)
15.719
_$ (test2)
15.938
_$ (test2)
15.719
_$ (test2)
15.688

But anyway, if you are at all interested in speed, the first task is compiling your program.

The same functions, the same computer, loaded as .fas:

_$ (test)
1.531
_$ (test)
1.532
_$ (test)
1.594

_$ (test2)
1.594
_$ (test2)
1.531
_$ (test2)
1.515

So, for compiled code the difference is negligible, and the program is about ten times faster.

-- 

[dbroad]

I would add that using separate setq statements makes programs easier to debug and to modify.

[martti.halminen]

In case anybody is interested in how other environments cope, I also ran the same test on Lispworks Common Lisp.

Running interpreted, it is actually slightly slower: 30 and 20 seconds.

Compiled code is approximately three times  faster than compiled Visual Lisp: 0.44 seconds. (un-optimized)

- The difference comes largely from Visual Lisp compiling to bytecode, which is run via a bytecode interpreter at runtime. Lispworks compiles to native machine code.

--