Skip to content

Rendering check only; the real pull request is PR 35 on andylokandy/arraydeque - #1

Closed
ajasmin wants to merge 2 commits into
masterfrom
bulk-extend-back
Closed

ajasmin wants to merge 2 commits into
masterfrom
bulk-extend-back

Conversation

@ajasmin

@ajasmin ajasmin commented Oct 1, 2026 •

Copy link
Copy Markdown
Owner

This was a rendering check of the pull request text before opening it upstream. Nothing to review here: the real pull request is PR 35 on andylokandy/arraydeque, from this same branch.

`const fn new` and `const fn capacity` sit in an impl with a
`B: Behavior` bound, which const fns accept only since 1.61
(`const_fn_trait_bound`), so the crate has not built on 1.59 since
3d9a1fd. Update the README, the crate docs and the CI matrix to 1.61,
and add `rust-version` to Cargo.toml so cargo reports the requirement
instead of failing mid-build.

While an LLM was used to help implement this, I can vouch for every line.
@ajasmin ajasmin changed the title Optimize extend_back; add extend_back_from_slice Optimize extend_back(); add extend_back_from_slice() Oct 1, 2026
The previous implementation of `extend_back()` pushed one element at a
time, each push recomputing the wrapped index, checking for a full
deque and storing `len`. Compute the free capacity up front as its (at
most two) contiguous regions and fill them with plain slice loops,
counting in a local that an `AddLenOnDrop` guard adds to `len` on exit,
so a panicking iterator keeps the elements already written and the loop
body is one unconditional store per element, which LLVM vectorizes for
primitive `Copy` elements from slice iterators.

The storage cast behind `as_uninit_slice_mut()` moves into a function of
the `xs` field, so `extend_back()` can borrow the storage and `len` apart
without unsafe code of its own.

Also add `extend_back_from_slice()` for `T: Copy`: one block copy per
free region, for element types the optimizer doesn't automatically
vectorize (odd sizes, padded structs) and for older compilers. The
copy goes through a private copy of std's `write_copy_of_slice()`
(stable since 1.93).

The `Wrapping` deque gets neither change. Its `extend_back()` overwrites
from the front once full, so filling the free regions is only its first
phase, and its `Extend` impl saturates rather than evicts (andylokandy#32); the
behavior's contract should be settled before touching the one or adding
the other.

While an LLM was used to help implement this, I can vouch for every line.
@ajasmin ajasmin closed this Oct 1, 2026
@ajasmin ajasmin changed the title Optimize extend_back(); add extend_back_from_slice() Rendering check (superseded) Oct 1, 2026
@ajasmin ajasmin changed the title Rendering check (superseded) Rendering check only; the real pull request is PR 35 on andylokandy/arraydeque Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant