5 ms·

How do you live in such a bliss ignorance where supposedly an order of magnitude difference in performance between two state of the art browsers doesn't make y

How do you live in such a bliss ignorance where supposedly an order of magnitude difference in performance between two state of the art browsers doesn't make you reconsider even for a second that you might have not written a working benchmark? :) Sorry but unless you have deep knowledge of how both engines and browsers work (knowing how `appendChild` is actually implemented for starters), you simply cannot write a working benchmark. Even then, it's very hard and tedious. If you don't have time to obtain such expertise, you could take a shortcut and compare realistic end-to-end benchmark. E.g. if your game runs at 210-270 fps in firefox but only at 30 fps in chrome, then you could claim that "firefox blows chrome out of the water". It's very easy (just look at 80%+ of jsperfs) to construct benchmarks that don't look completely broken to the untrained eye but actually are. The common theme is the benchmark missing many aspects of realistic code and being reduced to measuring irrelevant optimizing compiling features. For example the benchmark could only be measuring how thorough the engine's dead code elimination pass is even though what you wanted to benchmark is string concatenation performance.

consptheorist 11y ago
Last night I made some serious "soul searching" and deep profiling and I successfully identified the culprit by the aid of time distribution spent for every function call in the module and it actually was even way worse than I had expected because it was an EXTREMELY popular native DOM method. To add insult to injury, I also threw IE11 into the mix and did some test runs and surprise surprise it fared 2x-3x better than Chrome :). To give you a glimpse into the numbers: FF Dev 39: ~1000ms IE11: 2000ms - 3000ms Chrome42: 7000ms - 9000ms BTW, these test runs were performed on a very capable machine (released 2014). Just imagine what the numbers would be on challenged and less than optimal configs or mobile/tablet devices. Not really in Chrome's favor. So, under a real world scenario and real business problem and codebase, FF fared WAY WAY better than Chrome and even IE was ahead of Chrome too. No, I am not interested in those flawed benchmarks or skewed results peddled by intellectual masturbation pros like you, I only care about real world examples and business cases. Don't even bother asking about the offending method because I have a no asshole/douche allowed policy in place and it is not going anywhere anytime soon.

consptheorist 11y ago

Last night I made some serious "soul searching" and deep profiling and I successfully identified the culprit by the aid of time distribution spent for every function call in the module and it actually was even way worse than I had expected because it was an EXTREMELY popular native DOM method. To add insult to injury, I also threw IE11 into the mix and did some test runs and surprise surprise it fared 2x-3x better than Chrome :). To give you a glimpse into the numbers: FF Dev 39: ~1000ms IE11: 2000ms - 3000ms Chrome42: 7000ms - 9000ms BTW, these test runs were performed on a very capable machine (released 2014). Just imagine what the numbers would be on challenged and less than optimal configs or mobile/tablet devices. Not really in Chrome's favor. So, under a real world scenario and real business problem and codebase, FF fared WAY WAY better than Chrome and even IE was ahead of Chrome too. No, I am not interested in those flawed benchmarks or skewed results peddled by intellectual masturbation pros like you, I only care about real world examples and business cases. Don't even bother asking about the offending method because I have a no asshole/douche allowed policy in place and it is not going anywhere anytime soon.