IE10: How does it really stack up?
lucidchart.com
IE10: How does it really stack up?
1–10 of 67 posts
Re: IE10: How does it really stack up?
#2We gathered timing information for the parts of the benchmark that it did complete
Which parts didn't complete? Did you try the beta or aurora?
Code that can consistently crash firefox would probably be elgible for a security bounty.
Re: IE10: How does it really stack up?
#3My skills are a little rough and this is probably more than a company can devote to a browser war study but it would be interesting to see this benchmark run multiple times or as a Monte Carlo simulation.
Also - does anyone know what core runs at 50% in IE even when the user is idle? Not surprised to hear it but curious if anyone knows what it is.
Re: IE10: How does it really stack up?
#4My skills are a little rough and this is probably more than a company can devote to a browser war study but it would be interesting to see this benchmark run multiple times or as a Monte Carlo simulation. Also - does anyone know what core runs at 50% in IE even when the user is idle? Not surprised to hear it but curious if anyone knows what it is.
While idle, the profiler tells me that the function with highest time is yp at line 5198 in chart.js. But no idea whether that's really the culprit.
Re: IE10: How does it really stack up?
#5IE10 had to skip a bunch of frames and use half a core to not quite keep up with chrome and roughly match Firefox... Well, I suppose its an improvement still, but they had a pretty low bar to begin with.
Re: IE10: How does it really stack up?
#6Well, let's agree that IE10 does well whatever it is designed to do well. Cool. Now what? We have an IE10 browser that compares well with Google Chrome, Opera and perhaps Firefox too (I don't know the exact details about your tests that were making Firefox crash as often as you've claimed in your article).
So is this the point where Microsoft takes on the real challenge? Will it go beyond its typical high-speed sales pitch for the new browser and attack the more relevant problem that is to really get those IE6/IE7/IE8 and perhaps even IE9 users to adopt IE10 immediately?
Just a few days ago, I saw on HN how IE6 has become a political election issue in South Korea!
Pushing the lazy and entrenched users out of the hole is a much more important (and harder) problem to solve than to win medals over browser speed and performance tests. Even if tests like these help push the cause of IE10, it would be appropriate to give out all details of the tests and realize why Firefox was 'disagreeing' to your test at all?
Re: IE10: How does it really stack up?
#7There is one more strange thing about IE10 that I should mention. IE9 often maxes out one CPU core when a Lucidchart diagram is open, even when the user is completely idle. IE10 is somewhat better, but on our test machine it still used about 50% of one core when the user is idle. No other browser has any detectable CPU load under the same conditions.
Has anyone else seen behavior similar to this in their own javascripting (is that even a word?)? I hadn't been paying special attention to IE's CPU usage but I'd like to think I would have noticed this in any of my own stuff when I was doing browser compatibility testing.
Re: IE10: How does it really stack up?
#8My skills are a little rough and this is probably more than a company can devote to a browser war study but it would be interesting to see this benchmark run multiple times or as a Monte Carlo simulation. Also - does anyone know what core runs at 50% in IE even when the user is idle? Not surprised to hear it but curious if anyone knows what it is.
While idle, the profiler tells me that the function with highest time is yp at line 5198 in chart.js. But no idea whether that's really the culprit.
Hi, Lucid CTO here. We've spent a lot of time in the IE profiler, and it never appears that any of our Javascript is consuming much CPU at all. There are a handful of functions, like the one you quoted, that poll frequently on a setInterval. But none of them are doing much more than checking a variable and returning almost every time. It's really bizarre.
Re: IE10: How does it really stack up?
#9This should really be titled "IE10: How does it really stack up in one benchmark."
Re: IE10: How does it really stack up?
#10We gathered timing information for the parts of the benchmark that it did complete Which parts didn't complete? Did you try the beta or aurora? Code that can consistently crash firefox would probably be elgible for a security bounty.
Interestingly, the part that crashed Firefox was one of the simpler tests--typing a bunch of text content in, then resizing and rotating the shapes that contain that text. Firefox didn't give any details as to why it crashed.
The only thing I could even measure that would lead to a crash is memory usage. I just re-ran the test and watched the process's memory usage. It hovered in the 300-400MB range during the first third of the test. Then, during the test I describe, memory usage rocketed to around 1GB, at which point the browser crashed hard.
I'm not sure why Firefox would exhibit this behavior when other browsers don't, but we know a few people at Mozilla (they're customers of ours) so we'll probably reach out.