[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