Benchmark unfoldrN and inline createAndTrim'

[piyush-kurur]

In many cases one wants to unfoldr exactly so many bytes (e.g base16/base64 encoding). In such cases
a version of unfoldrN of the following type is quite useful (and probably faster)

unfoldrN' :: Int -> (a -> (Word8, a)) -> (ByteString, a)

Any reason why this is not yet present.

[Bodigrim]

Does unfoldrN' provide measurable performance benefits?

[piyush-kurur]

@Bodigrim not sure but likely as you avoid testing for both length as well as whether the function returns a Just/Nothing. But even if not relevant for speed, it would be good just for completeness.

[Bodigrim]

It seems there is a low demand for this function, and it can be easily defined on the user side:

unfoldrN' :: Int -> (a -> (Word8, a)) -> a -> (ByteString, a)
unfoldrN' n f s = fromJust <$> unfoldrN n (Just . f) s

Thanks to {-# INLINE unfoldrN #-} there will be no performance penalty for wrapping/unwrapping Just.

I'm quite reluctant to add new functions without a good justification, because they need to be implemented at least four times (lazy/strict ByteString, Word8/Char interfaces), plus potentially ShortByteString, plus ideally syncronized with Text.

---

That said, looking at Core program for unfoldrN I noticed that it could be better if we inline createAndTrim', similar to the existing pragma for createAndTrim.

[sjakobi]

I'm quite reluctant to add new functions without a good justification

👍

That said, looking at Core program for unfoldrN I noticed that it could be better if we inline createAndTrim', similar to the existing pragma for createAndTrim.

Sounds like a good idea to me.

[Bodigrim]

A PR adding {-# INLINE createAndTrim' #-} and benchmarks for unfoldrN would be welcome.

[piyush-kurur]

@Bodigrim The 4 time implementation is no fun. I agree with you that this may not be very useful.