-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
concat can be faster #550
Comments
Yeah, makes sense. I actually think that functions like this should not force the input list before starting to consume it. A usual pattern with doubling a mutable buffer on overflows would be better. |
That is also an option, but it has the disadvantage of overallocating. |
I guess your suggestion is a more conservative option. PRs welcome. |
I can make a PR 👍 |
Relaxing the type would be a breaking change (because some programs can stop typechecking due to excessive polymorphism), and I think there is no appetite for breaking changes that soon after |
I recently wanted a
reverseConcat
, which led me to the current implementation ofconcat
and the realization that it is not very efficient:text/src/Data/Text.hs
Lines 1033 to 1046 in e84c7a3
Text
s (lazily, but it still has a cost) because of the filtersumP
does not fuseHere is an alternate straightforward implementation:
This not exactly the same, since the current implementation performs a case match on the list after filtering out null
Text
s. But I doubt such a preemptive step helps.Benchmarks on GHC 9.6.3 with -O, concating a list of all
Char
s:Benchmark file
The text was updated successfully, but these errors were encountered: