On the elm blog post that was posted recently: http://elm-lang.org/blog/blazing-fast-html-round-two The benchmark linked at: https://evancz.github.io/react-angular-ember-elm-performance-comparison/ I've repeatedly had results like this in Chrome: <https://lh3.googleusercontent.com/-QjRiovQ7R-k/V_KsBTb1tDI/AAAAAAAAJJk/d9J0Xum785cer5TlJtjwt98zcfutIQxQgCLcB/s1600/UnusualResult1.png> Where the optimized version is showing to be slower than the unoptimized version of 0.17. Talked about it on slack last week and others saw the same oddity. Well after a lot of profiling and testing I think I found the issue, and it is not a fault of elm but rather of the testing infrastructure, specifically the runner.js times things by using setTimeout like: ``` // time ONE round of asynchronous work var asyncStart = performance.now(); setTimeout(function() { var asyncEnd = performance.now(); callback(syncTime, asyncEnd - asyncStart); }, 0); ``` Well according to the spec (talked about and linked from here <https://developer.mozilla.org/en-US/docs/Web/API/WindowTimers/setTimeout#Reasons_for_delays_longer_than_specified>) it used to be capped to 10ms or higher pre-html5 and starting on html5 it is capped to no faster than 4ms (although chrome does 2ms for 0ms callbacks in some versions but not others), and the functions run faster than 4ms in Elm 0.17, thus it is not actually testing the runtime but rather the runtime+timeout period. In browsers with slower javascript handlers (IE for example), or in browsers that do not seem to be following the spec on handler timeouts then I see the graph that I expect: <https://lh3.googleusercontent.com/-shwfvWAw4ls/V_KuS_KO6QI/AAAAAAAAJJw/eyofrLw-xewb58C7lEJs5NiPSXNziainwCLcB/s1600/UsualResult1.png> A work-around (from the above link as well) is to use `window.postMessage()` instead of `window.setTimeout()` as it is doing now as described here <http://dbaron.org/log/20100309-faster-timeouts>. I tried that and got these results in chrome (consistently): <https://lh3.googleusercontent.com/-KvxnGTIsrJA/V_K6-S6y0HI/AAAAAAAAJKg/r2uliPwzgV4X5jVjOsRWFb7C2ErymodCwCLcB/s1600/NewResult.png> I could not run Angular2 because it apparently does not render whenever it is called but rather 'later', thus its time reports were not even accurate on the original test. Significantly different test results though and I am not even sure if postMessage works in all corner cases and such either, but it does seem to fix the issue in chrome. Regardless, the 'lazy' calls in Elm 0.17 optimized contribute significantly to the speed and this way it is actually visible instead of the unoptimized and optimized showing almost identical times. :-) -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
