preliminary fast POSITION

Jörg Höhle — Tue, 18 Feb 2003 09:24:05 -0000

The sequence functions carry an immense amount of
overhead. As a result, POSITION, COUNT etc. are much
slower than one would expect.

I advocate that CLISP should recognize optimizable
cases and handle them internally. The time to test
internally at run-time for optimizable cases is
negligible compared to the full-blown sequence and
stepping overhead.

Specifically, I advocate that CLISP handles optimizable
cases transparently and does not expose something like
EXT:VECTOR-POSITION. CLISP should encourage portable
code and thus use of POSITION etc., with guarantees
that it will be fast where it can be.

Optimizable cases are, at a glance
o vector instead sequence (possibly only string or
unsigned-byte 8/16/32)
o and test EQ or EQL (or maybe CHAR= and = with
corresponding array element-type)
o with KEY #'IDENTITY
o :from-end is optimizable as well (means almost
duplicate code).

So far, I only implemented string-position, ignoring
test and from-end. Maybe somebody will want to
continue work from this.

Recent changes to 9: preliminary fast POSITION

preliminary fast POSITION