-
Notifications
You must be signed in to change notification settings - Fork 50
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
peekCAText is less efficient than it could be #79
Comments
@chessai We should think about it...
We should look at specs (if there are any) and think carefully about pros and cons... That can be a bit late though because we have already exposing |
Yeah, we're already using |
@chessai I think you are right, did you have a PR for this? |
@AlexeyRaga I opened an issue against |
currently it's just defined as
so, it not only calls the more inneficient peekCAString from base, but then it must convert the String into text! This seems unnecessarily expensive. There is an alternative in something similar to Data.Text.Foreign.peekCStringLen, which goes from CStringLen -> IO Text. There is a drawback to this, in that it only supports CStrings that are valid UTF-8, and throws an exception otherwise. Another drawback is that there's only a CStringLen variant, but that's not hard to get around:
This is almost exactly like
peekCStringLen
, but calls a different function from Data.ByteString.Unsafe, since there's no length information present.This seems like a good idea, if you're willing to sacrifice support for non-UTF-8. you could always use something like
bytestring-encodings.Data.ByteString.Encoding.isUtf8
(https://hackage.haskell.org/package/bytestring-encodings-0.2.0.2/docs/Data-ByteString-Encodings.html#v:isUtf8) to verify that the ByteString is UTF-8 encoded before proceeding, but then you'd probably have to return a 'Maybe Text', which doesn't seem worth it.The text was updated successfully, but these errors were encountered: