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

How does this compare to `arrayvec`'s `ArrayString`? #1

Open
ErichDonGubler opened this Issue Jan 21, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@ErichDonGubler
Copy link

ErichDonGubler commented Jan 21, 2019

No description provided.

@paulocsanz

This comment has been minimized.

Copy link
Owner

paulocsanz commented Jan 22, 2019

Our API is more extensible, it allows for unchecked write, truncating write, it never panicks in release builds.

There is no_std, serde and diesel integration where arrayvec has no_std and serde erroring (we truncate if the string is bigger, but this is debatable - we could make a Truncate newtype that truncates by default while the regular integration returns a error, or something like that).

Our approach to generics is a bit different, and we support any size from 1 byte to 255 bytes.

I've also benchmarked and this is the comparison (check the benches folder to analyze the micro benchmark). It's basically the same, but our implementation seems a bit faster (but it could be noise).

small-string  (23 bytes)      clone                  4.837 ns
small-string  (23 bytes)      try_from_str          13.552 ns
small-string  (23 bytes)      from_str_truncate     11.360 ns
small-string  (23 bytes)      from_str_unchecked    11.291 ns
small-string  (23 bytes)      try_push_str           1.162 ns
small-string  (23 bytes)      push_str               3.490 ns
small-string  (23 bytes)      push_str_unchecked     1.098 ns
-------------------------------------------------------------
arrayvec string (21 bytes)    clone                  7.725 ns
arrayvec string (21 bytes)    from                  14.794 ns
arrayvec string (21 bytes)    push str               1.363 ns
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment