SUBSEQ is slow for many array types

Bug #902537 reported by 3b
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
Undecided
Unassigned

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 http://ccl.clozure.com/irc-logs/sbcl/2011-11/sbcl-2011.11.07.txt starting at 13:15.

Png-read (https://github.com/Ramarren/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.

Tags: optimization
Revision history for this message
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
      type.

      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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.