[whatwg] API for encoding/decoding ArrayBuffers into text

On Mon, Mar 26, 2012 at 6:24 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Mon, Mar 26, 2012 at 7:33 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> Requiring callers to find the null character first, and then use that
>> will require one additional pass over the encoded binary data though.
>
>
> That's extremely fast (memchr), and it's probably the fastest thing to do
> anyway, compared to embedding null-termination logic into the inner loop of
> decode functions.

The memchr is purely overhead, I.e. we are comparing memchr+decoding
to decoding. So I don't see what's backing up the "probably the
fastest thing" claim.

> Unless there's a concrete benchmark showing that it's slower, and slower
> enough to actually matter, this shouldn't be a consideration.? It's a
> premature optimization.

My argument is that it's both faster and more author friendly.

I admit I missed the previous discussion which led to the agreement to
keep the length measuring outside, so I don't know what arguments were
presented. Any pointers would be appreciated.

>> Also, if we put the API for finding the null character on the Decoder
>> object it doesn't seem like we're creating an API which is easier to
>> use, just one that has moved some of the logic from the API to every
>> caller.
>
> It doesn't seem materially harder (a little more code, yes, but that's not
> the same thing), and it's more general-purpose.

I agree it doesn't seem materially harder. I also agree that I don't
have data to show that it's materially slower. But it sounds like
we're in agreement that keeping the logic outside is both harder and
slower which honestly doesn't speak strongly in its favor.

I don't understand the argument that the alternative is more
"general-purpose". The API is already generic in that you can use
whatever delimiter you want since you pass in a view. The only
functionality which is not available is finding a null-terminator in
an arraybuffer which you are arguing below shouldn't be part of the
decoder (which I agree with).

/ Jonas

Received on Monday, 26 March 2012 22:41:47 UTC