[Ecls-list] Slow prettyprinting (update)
Waldek Hebisch
hebisch at math.uni.wroc.pl
Thu Feb 14 19:02:01 UTC 2008
Juan Jose Garcia-Ripoll wrote:
> On Thu, Feb 14, 2008 at 3:26 PM, Waldek Hebisch
> <hebisch at math.uni.wroc.pl> wrote:
> > It looks that ECL version of 'assoc' is
> > slower than 'assoc' in other Lisp implementations (probably 1.5 - 3
> > times slower).
>
> Is this with user-provided test functions? Or using EQ, EQL or EQUAL?
>
I wrote: EQ. I have now a little artifical test:
(defvar *symbol-table* nil)
(defun init-symbol-table ()
(push (list #1='sym (list 1 #1#)) *symbol-table*)
(dotimes (i 100) (push (list #2='nosym (list 0 #2#)) *symbol-table*)))
(init-symbol-table)
(defun search-symbols (sym)
(let ((ress 0))
(dotimes (i 1000000)
(let ((pp (nth 1 (assoc sym *symbol-table* :test #'eq))))
(setf ress (+ ress (car pp)))
(setf sym (nth 1 pp))))
ress))
I have saved it to "ast.lisp" file and than compiled it. Then
I used command line like:
echo '(load "ast.fas") (time (search-symbols '\''sym))'| /var/tmp/hebisch/usr/bin/ecl
(with apropriate extension) to test various Lisps. I also varied list
length, keeping number of searches time length constant:
length 100 1000 2000 10000
sbcl 0.422 0.781 1.1 3.659
openmcl 0.470 0.908 1.290 2.919
gcl 0.510 2.060 2.200 5.960
ecl 0.830 1.970 2.209 6.428
clisp 2.82 2.37 2.53 3.51
Notes:
- I used default optimize/safety setting. gcl defaults to safety
0 and generates pretty unsafe code. In my experience default
sbcl code is pretty safe.
- All runs on 2Ghz Athlon 64 with 512 kb of L2 cache, in 64 bit
mode.
- On real data ecl seem to perform worse than in test above.
- On real data gcl profile indicates about 30 us per search which
would correspond to length of order 2000-3000 (if real data
have similar characteristics). But it is possible that length
is smaller, but data is fragmented meaning more cache misses.
--
Waldek Hebisch
hebisch at math.uni.wroc.pl
More information about the ecl-devel
mailing list