ˌbodʲɪˈɡrʲim
ˌbodʲɪˈɡrʲim
> ...and in principle we could make the search-result include such a badge for each result row > would that help? Certainly.
Do such functions benefit from inlining? Could this improvement be measured?
`INLINEABLE` itself allows specialization (but `dropWhile` is already monomorphic), but does not make GHC more inclined to inline. If we see a clear benefit from inlining, it should be marked...
Ah, I see. This is probably because of https://github.com/haskell/bytestring/blob/8c631dfdaaffdc5a42f94c66231577270d6301b1/Data/ByteString.hs#L959-L968 Could you try the similar set of rules for lazy `dropWhile`? It could be a more conservative option than inlining, without...
OK, then I suggest we do both, bringing lazy version in line with the strict one: mark `dropWhile` as `INLINE [1]` and add rewrite rules.
Ideally both strict and lazy `dropWhile (/= ' ')` should boil down to a `memchr` call in Core.
I'm not sure how `copyAddrToByteArray#` would help. There is no immediate `ByteArray` here.
Yeah, but I'm not convinced that an overhead for allocating redundant `ByteArray` header does not absorb potential savings from unrolled `copyAddrToByteArray#`.
Sorry, I meant `ByteArray#` header, which is memory until `byteArrayContents#`: header and array size, already 16 bytes.
This is a bug in tooling and there is a workaround available, so from my perspective changing public API is not quite justified. If there were no workaround, a better...