SUBSEQ is slow for many array types

Bug #902537 reported by 3b on 2011-12-10
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

SUBSEQ on (unsigned-byte 8) arrays (and probably most array types) ends up going through the slow path of MAKE-ARRAY,
eventually calling %vector-widetag-and-n-bits, which is slow (see bug #902533).

See discussion on #sbcl at starting at 13:15.

Png-read ( seems to do a SUBSEQ per pixel, so a 655x509 image takes 3.4 seconds to load, vs 0.6 seconds with an (unsigned-byte 8) special case added to %vector-widetag-and-n-bits.

Nikodemus Siivola (nikodemus) wrote :

commit fb2d28ba0ccab2afb9e68b4de722ba2179bcea8e
Author: Nikodemus Siivola <email address hidden>
Date: Sat Dec 10 19:07:53 2011 +0200

    faster VECTOR-SUBSEQ*

      Use a WITH-ARRAY-DATA to get to the underlying vector, and use a widetag
      dispatch table to pick the correct SUBSEQ implementation for the underlying

      This is actually just as fast even for simple strings as STRING-SUBSEQ*, so
      throw it out.

      Also make inlining SUBSEQ conditional on SPEED > SPACE now that the
      out-of-line version doesn't suck so much.

      Fixes lp#902537.

Changed in sbcl:
status: New → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers