Skip to content
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

Using ByteString internally? #19

Open
k0001 opened this issue Jun 6, 2020 · 4 comments
Open

Using ByteString internally? #19

k0001 opened this issue Jun 6, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@k0001
Copy link

k0001 commented Jun 6, 2020

Have you considered using ByteString internally, rather than Text? Considering bech32 values are likely to be stored/serialized as plain ByteStrings, seeing as they don't need any special encoding other than what plain old ASCII supports, having to convert back and forth between ByteString and Text for the purposes of parsing and rendering is wasteful.

@KtorZ
Copy link
Contributor

KtorZ commented Jun 8, 2020

Considering bech32 values are likely to be stored/serialized as plain ByteStrings

I disagree here. Storing data bech32-encoded as bytestring would be silly. In the same way that storing base16-encoded data as bytestring is silly. When encoding data in a human-readable format like these, the main purpose is for displaying into user interfaces (might it be a command-line in the console, a web interface or a desktop client ...)

Hence why Text is the chosen data-type from and to which data are decoded/encoded.

@rvl
Copy link
Contributor

rvl commented Jun 9, 2020

Both arguments have merit. Haskell Text is internally UTF-16, so double the space usage. I have found that I needed to sprinkle Data.Text.Encoding.encodeUtf8 when using this library (but wait, it's ascii not utf-8). Other bytes-to-text encoding functions use ByteString too. On the other hand, Text clearly denotes that the bech32 value is not unreadable binary data. So on this basis I prefer Text.

@k0001
Copy link
Author

k0001 commented Jun 9, 2020

Perhaps I wasn't clear. I am not suggesting getting rid of the Text support in the API, I am suggesting using ByteString internally, and exposing and API for encoding and decoding ByteStrings directly, alongside the already existing Text one. The Text-based API would encode/decode the Text as ASCII/UTF-8 and defer its work to the ByteString-based implementation.

In my case, I'm dealing with many bech32 values which are stored as ASCII/UTF-8 bytes, as part of other data structures. Unfortunately, Text can't use these bytes as they are, so they must be converted to the Texts internal UTF-16 representation (via Data.Text.Encoding.decodeUtf8). This add significantly to the processing time, unnecessarily.

@rvl
Copy link
Contributor

rvl commented Jun 10, 2020

OK, I looked at how the aeson library does this, as an example.

We may wish to switch it around and have the "default" API be the Text-based wrapper.

@jonathanknowles jonathanknowles added the enhancement New feature or request label May 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants