I think one day I would have raised this subject too. While doing [1] to
[3], 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
performances.
Maybe it's not uninteresting to look at [3] 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.
Regards,
[1] https://github.com/Ayms/node-Tor
[2] https://github.com/Ayms/iAnonym
[3] https://github.com/Ayms/abstract-tls and
https://github.com/Ayms/abstract-tls#performances-
Le 27/03/2013 01:18, Brendan Eich a écrit :
Kenneth Russell wrote:
On Tue, Mar 26, 2013 at 4:35 PM, David Herman<[email protected]>
wrote:
[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:
https://mail.mozilla.org/pipermail/es-discuss/2012-May/022834.html
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:
https://github.com/dherman/float.js/commit/deb5bf2f5696ce29d9a6c1a6bf7c479a3784fd7b
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?
/be
--
jCore
Email : [email protected]
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
