Vstr: C string library designed to work optimally with vector I/O
1–10 of 22 posts
Re: Vstr: C string library designed to work optimally with vector I/O
#2Sds from Antirez has a lot of the same features (not all), and is kept updated since it's used by redis and other projects. https://github.com/antirez/sds/blob/master/README.md
Vstr appears to have last been updated in 2006. It does have a comparison of different string libraries, though that's also dated: http://www.and.org/vstr/comparison
Re: Vstr: C string library designed to work optimally with vector I/O
#3Are these claims of O(1) behavior accurate? They might not be O(n), where n is the length of the string, but they sound likely to be O(v), where v is the number of 'iovec chunks' that the string is using (which could get large, depending upon how you are building up your strings)
Re: Vstr: C string library designed to work optimally with vector I/O
#4Sds from Antirez has a lot of the same features (not all), and is kept updated since it's used by redis and other projects. https://github.com/antirez/sds/blob/master/README.md Vstr appears to have last been updated in 2006. It does have a comparison of different string libraries, though that's also dated: http://www.and.org/vstr/comparison
SDS and this library are implemented completely differently...
Re: Vstr: C string library designed to work optimally with vector I/O
#5Sds from Antirez has a lot of the same features (not all), and is kept updated since it's used by redis and other projects. https://github.com/antirez/sds/blob/master/README.md Vstr appears to have last been updated in 2006. It does have a comparison of different string libraries, though that's also dated: http://www.and.org/vstr/comparison
"Vstr" seems to target zero-copy by storing a string as a collection of blocks of data. Sds, from my reading, is essentially Pascal strings for C.
They don't seem to be comparable.
Re: Vstr: C string library designed to work optimally with vector I/O
#6Are these claims of O(1) behavior accurate? They might not be O(n), where n is the length of the string, but they sound likely to be O(v), where v is the number of 'iovec chunks' that the string is using (which could get large, depending upon how you are building up your strings)
If your strings are short that's basically O(1), which could be nice for some workloads - enums, json keys, etc.
Re: Vstr: C string library designed to work optimally with vector I/O
#7Sds from Antirez has a lot of the same features (not all), and is kept updated since it's used by redis and other projects. https://github.com/antirez/sds/blob/master/README.md Vstr appears to have last been updated in 2006. It does have a comparison of different string libraries, though that's also dated: http://www.and.org/vstr/comparison
"Vstr" seems to target zero-copy by storing a string as a collection of blocks of data. Sds, from my reading, is essentially Pascal strings for C. They don't seem to be comparable.
It also targets "string like buffers" with arbitrary nulls, appends, splitting on a delimiter, and tokenizing. Yes, it works differently, and isn't readv/writev centric.
Re: Vstr: C string library designed to work optimally with vector I/O
#8Are these claims of O(1) behavior accurate? They might not be O(n), where n is the length of the string, but they sound likely to be O(v), where v is the number of 'iovec chunks' that the string is using (which could get large, depending upon how you are building up your strings)
If your strings are short that's basically O(1), which could be nice for some workloads - enums, json keys, etc.
That's not what O(1) means. If your strings are short, complexity doesn't matter either way.
Re: Vstr: C string library designed to work optimally with vector I/O
#9Are these claims of O(1) behavior accurate? They might not be O(n), where n is the length of the string, but they sound likely to be O(v), where v is the number of 'iovec chunks' that the string is using (which could get large, depending upon how you are building up your strings)
If your strings are short that's basically O(1), which could be nice for some workloads - enums, json keys, etc.
That's still misleading.
If all my input is small then O(n^2) is basically O(1) as well.
Re: Vstr: C string library designed to work optimally with vector I/O
#10Are these claims of O(1) behavior accurate? They might not be O(n), where n is the length of the string, but they sound likely to be O(v), where v is the number of 'iovec chunks' that the string is using (which could get large, depending upon how you are building up your strings)
If your strings are short that's basically O(1), which could be nice for some workloads - enums, json keys, etc.
if all your strings are of size < c, you can do any string operation on a single string in constant time.