vitteaymeric at gmail.com
Wed Mar 27 07:05:05 PDT 2013
I think one day I would have raised this subject too. While doing  to
, I was wondering during some time if I was using typed arrays
correctly, because I found strange to have to create each time a
DataView of a possible enormous buffer to read 2 bytes, and what the
impact on performances.
Not talking about node.js that "does not care" about the fact that their
DataView instantiation is ridiculously slow, it appears that the defect
is present in FF too up to a certain version but it's corrected in the
latest Nightly, so probably the answer is that there is an impact on
Maybe it's not uninteresting to look at  where I am trying to compare
3 methods (former "string" buffers, typed arrays without DataViews, and
typed arrays with DataViews)
Or maybe I am still not using this correctly, all protocols used here
are in big endian order, I did not read everything about the subject and
why this decision was made but the basic reflex would be to add an
endianness option to typed arrays.
 https://github.com/Ayms/abstract-tls and
Le 27/03/2013 01:18, Brendan Eich a écrit :
> Kenneth Russell wrote:
>> On Tue, Mar 26, 2013 at 4:35 PM, David Herman<dherman at mozilla.com>
>>> [breaking out a new thread since this is orthogonal to the NaN issue]
>>> While the Khronos spec never specified an endianness, TC39 agreed in
>>> May 2012 to make the byte order explicitly little-endian in ES6:
>>> The de facto reality is that there are essentially no big-endian
>>> browsers for developers to test on. Web content is being invited to
>>> introduce byte-order dependencies. DataView is usually held up as
>>> the counter-argument, as if the *existence* of a safe alternative
>>> API means no one will ever misuse the unsafe one. Even if we don't
>>> take into account human nature, Murphy's Law, and the fact that the
>>> web is the world's largest fuzz tester, a wholly rational developer
>>> may often prefer not to use DataView because it's still easier to
>>> read out bytes using [ ] notation instead of DataView methods.
>>> I myself -- possibly the one person in the world who cares most
>>> about this issue! -- accidentally created a buggy app that wouldn't
>>> work on a big-endian system, because I had no way of testing it:
>>> In summary: we already agreed on TC39 to close this loophole, it's
>>> the right thing to do, and concern about potential performance
>>> issues on non-existent browsers of non-existent systems should not
>>> trump portability and correctly executing existing web content.
>> I am disappointed that this decision was made without input from both
>> of the editors of the typed array spec and disagree with the statement
>> that it is the right thing to do.
> First, my apologies to Dave for forgetting the May decision. I was
> looking in the wrong place for a record of that decision!
> Second, I understand Ken's point of view (old SGI hacker here) but
> have to question it on the grounds Dave raises: no one is testing, so
> there are very likely to be latent little-endian dependencies in
> deployed code today.
> So why not codify this? Because it might penalize big-endian systems?
> The IP protocols use big-endian byte order (owing to the pre-Intel
> big-endian architectures of IMPs and early Internet machines) and so
> penalize Intel machines, and we take the hit (and it's small on modern
> super-scalar CPUs).
> Ken, a couple of questions:
> 1. Do you know of any big-endian systems with market share that host
> JS implementations? It would be great to have a list.
> 2. Independent of the answer to (1), today's web browsers run on
> little-endian systems and that has very likely created a de-facto
> standard. If we codify it, we make the small to empty set of
> big-endian systems pay a price. Why is this the wrong thing for typed
> arrays but the right thing (in reverse! majority-architectures
> penalized) for the IP protocol suite?
Email : avitte at jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
More information about the es-discuss