I think scatter/gather support is the only feature I've seen discussed that's not supported by std::rope (I only looked at GCC's, but it seems to support sharing of common substrings). And if you don't need fast concatenation (i.e. due to sharing), then you could use a const std::dequeue. So, unless I'm missing something, I think the question is pretty much down to the value of scatter/gather I/O. Now, I'm skeptical about the real-world benefits of scatter/gather I/O, over simply copying into a contiguous temporary buffer. It turns out GNU's libc will even do this automatically and transparently, if you exceed the I/O vector length limits of the kernel. RAM is just so much faster than even 10 Gig ethernet and SSDs. And since L3 cache is bigger than typical socket buffer sizes, you'll often find that emulating scatter/gather in userspace is essentially free. It wasn't always this way, but I'd argue that scatter/gather I/O something of an anachronism - it just isn't worth the trouble, any more. Does anyone know of any recent benchmarks on scatter/gather I/O? If I'm wrong, I'd like to know it. I did a quick search, but came up empty-handed. I saw something on LKML that seemed to compare it to a sequence of synchronous reads/writes to a file with O_SYNC, but I'm talking about replacing it with a copy + single read/write. I'm guessing you'd have to use a ramdisk for the difference to be measurable. Speaking of benchmarks, I ran across an old benchmark of GCC's std::string vs. STLport's std::string & std::rope. I don't know if the results are still relevant, but it has some string benchmarking code you could reuse (I think someone mentioned benchmarking it against other strings, earlier in the thread). http://complement.sourceforge.net/compare.pdf Matt ________________________________ From: boost-bounces@lists.boost.org on behalf of Mathias Gaunard Sent: Fri 3/18/2011 6:37 AM To: boost@lists.boost.org Subject: Re: [boost] Boost.Chain over at Github On 18/03/2011 03:49, Dean Michael Berris wrote:
That's fine, I deal with lots of network I/O as part of the HTTP implementation in cpp-netlib and it would be really good if I can step away from std::string from the internals to support larger strings without having to induce too much fragmentation when concatenating strings. The intention is to have suitably efficient (not necessarily optimal) string representations for code that need to deal with both small and potentially huge strings.
Then you need a string which layout is compatible with the vectored I/O API provided by the system (readv/writev on POSIX, ReadFileScatter/WriteFileGather on Win32). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost