Skip to content

QR refactor! rebuilds the bordered matrix every call (~114 KB) instead of updating values in place — fix the advertised hot path #7

@ChrisRackauckas-Claude

Description

@ChrisRackauckas-Claude

WHAT: The csr_refactor! kernel is allocation-free, but the refactor! wrapper (src/qr.jl:151-160) rebuilds the entire bordered matrix on every call. Measured breakdown (n=200, r=3): _augmented_matrix rebuild of [S Usp; Vsp negI] = 96,072 B, CSC→CSR conversion = 18,272 B, kernel = 0 B, total = 114,200 B/call. The refactor!(F, A) form measures ~320 KB/call in the infra audit. WHY IT MATTERS: This is the Newton/time-stepping hot path the package advertises as its throughput story; the docstring (src/qr.jl:147-149) already concedes it is 'not yet fully zero-allocation', and the README (line 82) overstates allocation-freeness for the refactor!(F, A) form a Newton loop naturally uses. FIX: Mirror the LU augmented path (src/augmented.jl:134-141): build the bordered CSC/CSR once at construction and store it; on refactor! overwrite only the nonzero value slices from the new S/U/V (the negI block and selector-U ones are constant; only S and V values change since the pattern is fixed for given (n,r) and S pattern), then call csr_refactor! on the same CSR buffer. Requires a value-only writer into the stored CSR. As part of the same change, qualify README line 82 to say allocation-freeness applies to the cheap refactor!(F, nzval) form, not refactor!(F, A). EFFORT: M.


Priority: high. Filed from an automated next-steps audit of the QR/lstsq work (see PR #6).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions