Per Hedbor wrote:
Sorry about the timing, I have had IOBuffer on the way for some time (I am still wondering where to put it, however, that has, believe it or not, been a blocker for me. Perhaps Stdio.Buffer? I will create a buffered stream that reads to and writes from said object, without creating pike strings)
Well, before giving a final resting place, consider my additions to String.Buffer, then decide which to squash and where to put it.
Unfortunately it is not possible to make String.Buffer even close to as efficient as long as it uses a stringbuilder. And not using a stringbuilder slows some things down (sprintf comes to mind) and makes others more or less impossible (wide strings) without excessive code duplication.
Well, we do the difficult today, the impossible tomorrow. And considering that I've been tracking your IOBuffer changes almost instantly locally here, I'd say I've already done the impossible a few days ago :-).
The whole reason for IOBuffer is that it uses pointer arithmetics on guaranteed 8bit strings to be fast at both reading from the beginning and writing to the end at the same time (I am, by the way, considering converting it to be a circular buffer to avoid the one memmove it does at times), and it is also efficient at creating sub-buffers.
Well, I'm not sure that a circular buffer will really help, since it introduces buffer-wrap checks. Generally speaking, buffers help enormously when reading and parsing from bytestreams into pike, but they do not help all that much when writing to bytestreams. The writev() system call handles the fragmented writes quite nicely (see the pgsql driver) and more efficient than an IOBuffer which would copy the data at least once.
Things like subbuffers is unfortunately actually impossible when using a stringbuilder.
Well, it's not, really. Unless I made some rather striking mistakes.
The main goal here is to do one copy less and avoid the pike string creation
The reading case needs that, the writing case not so much.
Well. You have some minor optimizations to do:
You're looking at v1.1 of String.Buffer, I already have v3.0.
perf( String.Buffer() );
Result 2: 325250971 Compilation: 624ns, Execution: 144.86s
Erm, how do you get this nice looking timings? Do I have to turn on a profiling flag on Hilfe somewhere?