from JSC to all others: preciseTime global function ?
What about high resolution time? dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html
David
Le 16/08/2012 13:42, Andrea Giammarchi a écrit :
looks like the result would be the same obtained via preciseTime() * 1000000 ... I just wonder why this is a W3C draft rather than a ECMAScript one.
meanwhile ... for JSC, Rhino, node.js, and browsers ...
// JSC has it right, kudos! (typeof preciseTime == "undefined" && function(exports){ var preciseTime; try { // node.js + does it work ? (preciseTime = require("microtime").nowDouble)(); } catch(o_O) { try { // Rhino + does it work ? var nanoTime = java.lang.System.nanoTime; (preciseTime = function preciseTime() { return nanoTime() / 1000000000; })(); } catch(o_O) { // browsers ... it works preciseTime = function preciseTime() { return new Date / 1000; }; } } exports.preciseTime = preciseTime; }(this));
//* test var t = [+new Date / 1000, this.preciseTime()]; try { console.log(t); } catch(o_O) { try { alert(t); } catch(o_O) { print(t); } } //*/
br, Andrea Giammarchi
Le 16/08/2012 14:02, Andrea Giammarchi a écrit :
looks like the result would be the same obtained via preciseTime() * 1000000 ... I just wonder why this is a W3C draft rather than a ECMAScript one.
Same question stands for setTimeout/setInterval, setImmediate, WebWorkers or the crypto API to name a few others. Same question for the sync worker API I heard about only today (no implementation yet as far as I know).
Habits would be my best guess. W3C is seen as the source on Earth of web standards, so a lot of people have the reflex to start a W3C/WHATWG draft rather than considering in which technology their problem would be best solved. ECMA TC39 also (mistakenly) bought itself a bad reputation of being slow to standardize things in smoky rooms. I think it's changing slowly, but we'll keep seeing for some time drafts of features that should belong to the language level in W3C drafts.
I agree a preciseTime function would better belong in ECMAScript, but all in all, it does not really matter, as webdevs, we just need the features regardless of where they're spec'ed.
Eventually there will only be a unique "web platform" standard-body-neutral meta-spec anyway... I mean... right? eventually? please? :-)
Jokes aside, I really hope the concurrency strawman will be on track for ES.next.next (ES7) and all concurrency-related features in the rest of the web platform (event loop, timeouts, web workers...) can be specified on top of that.
fair enough :D
Quick one, since I have discovered this only recently via Object.keys(this) in JSC ( JavaScriptCore )
double <= preciseTime()
returns a double number with seconds and microseconds, e.g.
12334556.123456
is basically the same of doing (new Date / 1000) except the precision is up to 1000000.
in Java/Rhino, System.nanoTime() / 1000000000 would produce similar result, but I found preciseTime() accurate enough but not as slow as nanoTime historically is ( greedy in clocks )
Is ES6 considering this function? I find hilarious that all JS benchmarks out there are basically asking browsers to enable a Java Applet in order to have better precision ( without considering that both binding and callback are more expensive than any +new Date call )
Thanks for any sort of answer.
Best , Andrea Giammarchi
Quick one, since I have discovered this only recently via Object.keys(this) in JSC ( JavaScriptCore ) double <= preciseTime() returns a double number with seconds and microseconds, e.g. 12334556.123456 is basically the same of doing (new Date / 1000) except the precision is up to 1000000. in Java/Rhino, System.nanoTime() / 1000000000 would produce similar result, but I found preciseTime() accurate enough but not as slow as nanoTime historically is ( greedy in clocks ) Is ES6 considering this function? I find hilarious that all JS benchmarks out there are basically asking browsers to enable a Java Applet in order to have better precision ( without considering that both binding and callback are more expensive than any +new Date call ) Thanks for any sort of answer. Best Regards, Andrea Giammarchi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120816/68867965/attachment-0001.html>