Skip to content

Add NonEmpty variants of inits and tails - #557

Merged
clyring merged 5 commits into
haskell:masterfrom
clyring:initsNE
Nov 28, 2022
Merged

Add NonEmpty variants of inits and tails#557
clyring merged 5 commits into
haskell:masterfrom
clyring:initsNE

Conversation

@clyring

@clyring clyring commented Nov 20, 2022

Copy link
Copy Markdown
Member

See #552.

The lazy versions use new implementations:

  • Lazy tails got about 10% faster. (A happy accident!)
  • Lazy inits got much faster:
    • For the first few chunks it is about 50% faster, due to better fusion.
    • When there are many chunks it is about 2.5x faster.

The performance of the strict versions is unchanged. The inits benchmark with small chunks is on the slow side, taking a little over 100ms on my machine.

The lazy versions use new implementations:
- Lazy tails got about 10% faster. (A happy accident!)
- Lazy inits got much faster:
  - For the first few chunks it is about 50% faster, due to better fusion.
  - When there are many chunks it is about 2.5x faster.
@clyring clyring linked an issue Nov 20, 2022 that may be closed by this pull request

@Bodigrim Bodigrim left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great stuff!

Comment thread Data/ByteString/Lazy.hs Outdated
Comment thread Data/ByteString/Lazy.hs
@clyring

clyring commented Nov 23, 2022

Copy link
Copy Markdown
Member Author

It looks like my original run of the Lazy.tails benchmark with ghc-9.4 was simply unlucky. This patch actually seems to regress runtime of that benchmark by somewhere around 5-8% with ghc-9.4.3 on my machine. (It does really improve by 10% with ghc-9.2.5.) I tried looking into it but haven't found any clarity. In fact, when I revert the changes to Lazy.tails entirely but keep the rest of the patch I still observe it getting 5-8% slower than it was before the patch. So I'm inclined to ignore this regression.

Fixing the order of composition in lazy inits made the small-chunks version of that benchmark go from 2.5x faster to 4x faster than the original code. (This is because only the wrong-way composed function needed to allocate a thunk when called.)

Comment thread Data/ByteString.hs
@clyring
clyring requested a review from sjakobi November 25, 2022 00:19
@clyring
clyring merged commit d4933c6 into haskell:master Nov 28, 2022
@Bodigrim Bodigrim added this to the 0.11.4.0 milestone Nov 28, 2022
vdukhovni pushed a commit to vdukhovni/bytestring that referenced this pull request Dec 7, 2022
* Add basic benchmarks for inits/tails

* Add NonEmpty variants of inits and tails

  The lazy versions use new implementations:
  - Lazy tails got about 10% faster with ghc-9.2. (A happy accident!)
  - Lazy inits got much faster:
    - For the first few chunks it is about 1.5x faster, due to better list fusion.
    - When there are many chunks it is about 4x faster.

* Formatting and comments, as suggested in review

* Add link to a relevant CLC issue about NonEmpty

  - haskell/core-libraries-committee#107
clyring added a commit that referenced this pull request Dec 29, 2022
* Add basic benchmarks for inits/tails

* Add NonEmpty variants of inits and tails

  The lazy versions use new implementations:
  - Lazy tails got about 10% faster with ghc-9.2. (A happy accident!)
  - Lazy inits got much faster:
    - For the first few chunks it is about 1.5x faster, due to better list fusion.
    - When there are many chunks it is about 4x faster.

* Formatting and comments, as suggested in review

* Add link to a relevant CLC issue about NonEmpty

  - haskell/core-libraries-committee#107

(cherry picked from commit d4933c6)
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.

Provide a version of inits, tails :: ByteString -> NonEmpty ByteString

3 participants