Custom Query (1030 matches)

Clozure CL "Version 1.8-r15286M  (LinuxX8632)"

(defun test ()
  (let ((bit-arr (make-array 1000 :element-type 'bit :initial-element 0)))
    ;; Set one bit in the array, for #\A
    (setf (aref bit-arr (char-code #\A)) 1)
    (let ((num-chars 1)
          (char-arr (make-string 1)))
      ;; loop over the bit array, finding the bit, and putting #\A in CHAR-ARR
      (loop for src-char-code fixnum from 0
            with ret-ix fixnum = 0
            when (= (sbit bit-arr src-char-code) 1)
            do (progn (setf (schar char-arr ret-ix) (code-char src-char-code))
                      (incf ret-ix)
                      (if (= ret-ix num-chars)
                          (return)
                        (warn "(ret-ix) ~A != ~A (num-chars)" ret-ix num-chars))))
      char-arr)))

Running gives:

  Warning: (ret-ix) 1 != 1 (num-chars)
  ; While executing: COMMON-LISP-USER::TEST, in process listener(1).
  > Error: Array index 1000 out of bounds for #<SIMPLE-BIT-VECTOR 1000>

Removing the FIXNUM declaration for RET-IX inside the loop solves it:

  ..
  with ret-ix = 0
  ..

I built a hash table with keys that were simple cons cells of the form

(<type> . <item>)

I had a few <type>s, and lots of atomic <item>s (in particular, strings) for each <type>. The performance was very bad.

Investigation showed that ccl::compute-hash-code was returning a hash code that depended only on the <type> but not on the <item>, meaning that hash table look up was degenerating into a linear search.

Example:

(setq h (make-hash-table :test #'equal))

Then

(ccl::compute-hash-code h '(type . "foo") nil)
(ccl::compute-hash-code h '(type . "bar") nil)
(ccl::compute-hash-code h '(type . "baz") nil)
(ccl::compute-hash-code h '(type . pi) nil)
(ccl::compute-hash-code h '(type . nil) nil)

all return exactly the same results.

Under some circumstances apply is passing NIL as an optional parameter to an inlined function, instead of passing the default argument. (see attached paste from REPL)