Repository navigation
Why String? #38
Description
There's a lot of usage of "strict" Strings in the package. Is there a good reason not to use Text? Particularly since there's a dependency on Aeson (and probably others), Text is already an indirect dependency. using !String just forces the list constructor, and leaves the tail of the list unevaluated (and also causes an under the hood conversion from Text to String within Aeson).
Activity
NickSeagull commentedon Jul 5, 2019
We were using
TextbeforeString(we dont useStringin our projects generally), but we found that usingTextwas a tiny bit slower somehow (I guess because we were doing lots of conversions). There wasn't any thorough benchmarking. But we will do it in the near future, so we can have much better data on that. And if needed, we will switch over toTextagain :)jacobstanley commentedon Aug 14, 2019
I just came to ask exactly this, measurement ftw.
Have you tried
ByteString? My gut saysTextUTF-16 can be problematic for sure when you're not doing a lot of string manipulation. Especially since aeson reads utf8 bytes via attoparsec (if I recall correctly) so it needs to be converted back to that anyway.NickSeagull commentedon Aug 17, 2019
Yeah, this was going to be the next step @jacobstanley . But still, there are no benchmarks yet 😅 , it'd be great to have something to measure that
axman6 commentedon Apr 9, 2020
Any update on this? I can't see any way in which String would be faster than Text, since the String needs to be parsed from a Text in the Aeson Value type. I'd really like to try moving some of out lambdas to the native runtime but seeing things like this makes me worry about the project.
NickSeagull commentedon Apr 9, 2020
The decision of using
Stringwas due to what was said above. Most of the inputs are provided by AWS as environment variables, which is read as aStringby default, having to convert back and forth betweenTextandStringwas troublesome because there were so many unnecessary conversions.In what way? If your worry is about exposing
Stringto the public API, it could be easily changed.axman6 commentedon May 6, 2020
Sorry for the late reply on this, and apologies for my misunderstanding. I had forgotten how much was passed to the native runtime as Strings from env vars. I should look into making a version of System.Environment which uses ByteString, to avoid the conversion to String all together...
axman6 commentedon May 6, 2020
If you can bare the dependency on the
unixpackage, you can use https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-Env-ByteString.html to grab the env vars. Personally I'd prefer to have these as ByteStrings and make conversions to other types if I need them.