proposal: DataView.prototype.toString(start = 0, end = this.length, enc= "utf8")
isiahmeadows at gmail.com
Thu Aug 23 00:09:09 UTC 2018
DataView has nothing to do with this performance-wise - implementations
could just use the raw array buffer instead, and it'd be quicker and easier.
The issue is string representation - engines can optimize for it in ways
you can't at the language level.
On Wed, Aug 22, 2018 at 16:51 Ken Russell <kbr at google.com> wrote:
> If DataView's methods were faster, would this eliminate the need for this
> In the V8 engine, some recent work significantly improved DataView's
> performance. See http://crbug.com/225811 for details.
> On Tue, Aug 21, 2018 at 7:02 PM Isiah Meadows <isiahmeadows at gmail.com>
>> You might be interested in some of the things I have here:
>> I'm not quite to the point of pushing TC39 to consider, but after I get
>> around to sorting it better, I'd love to see all of them eventually
>> Note that for some common cases, like to ASCII or UTF-8 when no character
>> in the string is above U+007F or to UCS-2/UTF-16 when at least one
>> character is above that, it's a trivial `memcpy` for multi-character
>> On Tue, Aug 21, 2018 at 18:32 Ali Rahbari <rahbari at gmail.com> wrote:
>>> When working with binary data, reading string from buffer is a
>>> necessity. For example when deserializing bson data in the browser.
>>> Most of node.js buffer methods are available in DataView except
>>> toString. As a workaround currently it's done by reading the buffer byte by
>>> byte and convert each of them to corresponding character with
>>> String.fromCharCode() and then joining the result.
>>> This can be done much faster in native code.
>>> DataView.prototype.toString(start = 0, end = this.length, encoding=
>>> DataView.prototype.writeString(string, offset = 0, length =
>>> string.length, encoding = "utf8")
>>> Ali Rahbari
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss