Feature/faster crypto

[indutny]

Right now this is only about crypto.createHash().update().digest(), but soon will add other methods here if you do not have any objections.

cc @bnoordhuis . Btw, would be nice to have @iojs/crypto

[indutny]

Btw, it still spends >15% of time in malloc()/free().

[indutny]

Whoa replaced all uses of StringBytes in crypto. @bnoordhuis: please take a look.

[indutny]

Ha, just created @iojs/crypto

[indutny]

Oh, forgot to say. Overall improvement is about 15%.

[bnoordhuis]

You can probably do a little better still by also passing encoding->length(). Then you can filter on length first before you start comparing bytes.

[bnoordhuis]

Also, wouldn't it be cheaper to do the comparison in JS and just pass integers to C++ land? I suspect that the biggest overhead is from the new[]/delete[] calls, not the string comparison.

[indutny]

I'm +1 for JS-land thing, but for now - let's do it the way it is. encoding->length() doesn't seem to be improving situation much on my benchmarks.

[bnoordhuis]

LGTM. Left some comments but nothing substantial.

[indutny]

Landed in c6367e7, aca2011, 3d4e96f. Thank you!

[piscisaureus]

Speaking of naming, I think StringBytes::InlineDecoder isn't the greatest of names either.

[indutny]

@piscisaureus suggestions?

[piscisaureus]

First of all the Inline part is misleading; this class doesn't inline anything, it tries to avoid memory allocations. So EmbeddedDecoder or OnStackDecoder would have been better, the latter being more clear about the intended use case but not necessarily true.

To take it a step further, an InlineDecoder instance basically represents a string that's been copied out of the v8 heap so an appropriate name would be StringBytes (*).

The current StringBytes type actually doesn't represent anything, it's basically acts as a namespace for a couple of jsstring-to-cstring conversion helper functions. A better name would be StringDecoder. Where I think Decoder isn't free of confusion, maybe Convertor would be better?

(*) You might argue that the InlineDecoder just represents a memory allocation, because it's possible to call Decode() multiple times. However it looks like it's unsafe to do so; I wonder why you made Decode a method in the first place. In other words I think InlineDecoder::InlineDecoder (Handle<String> string, Handle<Value> encoding, enum encoding default_encoding) would have been a more appropriate signature for the constructor.

[piscisaureus]

BTW I think this is a good addition.
There are other cases where v8::String::Utf8Value causes many small memory allocations; using this approach would make it more efficient.

[indutny]

@piscisaureus there is no v8 API to do such on-stack allocations.

[indutny]

@piscisaureus oh, we could use WriteUtf8!

[indutny]

@piscisaureus opened a PR as you suggested #670