part: Fixed bug where `cap` may grow above buffer-halve length (in `SearchSeq` and `SearchPar`.)
part: TODO: Added test skeleton for testing `SearchSeq` and `SearchPar` correctness. Implement these tests!
Fortune for reverse's current commit: Small blessing − 小吉
letmax_cap=matchget_max_pivot_search_area(haystack.len()>(DEFAULT_PIVOT_MAX_SEARCH_AREA*DEFAULT_MEM_DETECT_HUGE_SIZE_PAGES)){// Assume huge-page memory if len is larger than 4 pages.
// On debug builds, cap search area to one system page only.
@ -266,3 +319,36 @@ where S: MidpointFBSearcher<u8>
//XXX: Should we add a `SearchAsync`? Or an impl for SearchPar that uses already-spawned threads? TODO: It would be best if we could re-use extant threads instead of spawning two on each partition...
//XXX: Should we add a `SearchAsync`? Or an impl for SearchPar that uses already-spawned threads? TODO: It would be best if we could re-use extant threads instead of spawning two on each partition...
//Parallel (feature="threads") byte area partition-on-nearest-newline-to-halve impl, and non-parallel (default) impl. These impls can differ in their desired depths of partitioning (using parallel impls should balance num of partitions to num of logical cpus & input(/desired chunk) size.)
//Parallel (feature="threads") byte area partition-on-nearest-newline-to-halve impl, and non-parallel (default) impl. These impls can differ in their desired depths of partitioning (using parallel impls should balance num of partitions to num of logical cpus & input(/desired chunk) size.)
//TODO: Add tests for `Search{Seq,Par}` partitioning methods.
//TODO: Thread-reusing parallel `MidpointFBSearcher` (SearchSeq is thread-*spawning*; heavy.) This may require we use async and tasks. If it does, we should also create a `SearchAsync` partitioner (XXX: MidpointFBSearcher is currently a synchonous-only interface; a pure-async pivot finder may require a refactor.)