I wish this post included some benchmarks or measurement.
For old numbers, you can get some in some of my old presentations at conferences. I think the LCA 2015 one[1] has the most details in that regard.
101–110 of 144 posts
I wish this post included some benchmarks or measurement.
For old numbers, you can get some in some of my old presentations at conferences. I think the LCA 2015 one[1] has the most details in that regard.
Earlier quoted context omitted.
As soon as there are parent selectors, the pointers don't help. Specifically, if I restyle a parent, all children of parent need to be adjusted, right? Siblings... I'm assuming there is nothing hard there. Positions, maybe?
I still don't see what problem parent selectors cause. Restyling parent happens anyway without parent selectors (say, by JavaScript), so it is handled. In https://github.com/servo/servo/blob/master/components/style/... , MustCascadeChildren is returned when you... must.
I was also shooting from the hip for things I'm interested in, here. I'm not sure it matters. But, if on scanning, you pick relevant rules to apply based on the path to a node, then I could see some trickiness on having to consider both the top down and the bottom up paths to a node.
Siblings.., I don't think has this problem. Not sure why I thought it might.
And javascript is ultimately a different topic. So I wasn't worried about that here.
Earlier quoted context omitted.
I'm well aware of that. I also know that, in general, having to schedule things slows them down. If everything I'm running is trying to schedule something on my entire machine, it is giving my OS more work. Which will, by necessity, be harder to schedule and slow things down. I'm not necessarily against all of this, but I'm also not eagerly embracing more crap to slow down my machine for no apparent reason.
You are assuming that your OS scheduler is nearly at capacity, it isn't. And moreover your CPU is will spend most of it's life idle. I could almost guarantee you this is not the bottleneck of any modern setup.
Now, if the browser becomes more and more consuming, hitting my browser could get closer and closer to kicking off another giant compile.
I always wonder, who puts together nifty little blog posts on this kind of thing complete with graphics just for the article? By that I mean, literally what title do they have? Myself and my colleagues would/could write up a technical breakdown of something neat or innovative we might have done to solve some problem at work, but we sure as shit can't make cool little graphics interspersed between opportune paragraphs…
No, I created Code Cartoons in my spare time. After I worked at Mozilla for a while, I pitched the idea of me making Code Cartoons explaining the things we were developing in Emerging Technologies. My (current) boss was super into the idea. I talked more about this on a recently recorded Hanselminutes podcast. It should come out soon.
Parallel processing demonstrates benefits only if you have physical cores to run code on them. If just one core is available for the app then parallel processing is a loss due to thread preemption overload. Is there any real life examples of achieved speedup?
Note that Stylo is still faster than the old Gecko system even in sequential mode.
Earlier quoted context omitted.
In general, yes. That my computer can do many things is something I take advantage of as a user. The programs should use them to their advantage, but by and large, most programs do not need all of the processing capabilities of my computer, so I expect they should play well together. (Indeed, it takes effort to get the GPU of my computer to help out with anything.)
Keep in mind that by parallelizing work the browser can finish the work it's doing faster, which means your CPU can spend more time idle, which is better for power consumption.
And, as others, you are also assuming I was not pegging out my machine doing something by choice.
Earlier quoted context omitted.
> Is there any real life examples of achieved speedup? Yes, most pages have significant speedups during the initial restyle especially. Wikipedia pages tend to get 3x or so improved style recalc time on typical systems with Intel quad core CPUs, for example. Of course, styling is only one part of the whole, so your overall speedups are limited by the rest of the rendering pipeline. That's Amdahl's Law for you. But th…
> Wikipedia pages tend to get 3x or so improved style recalc time on typical systems with Intel quad core CPUs, for example. Do you have absolute numbers? If it's 100 vs. 300 ms, that'd be huge. If it's 1 vs. 3 ms, I don't really care.
Earlier quoted context omitted.
> Wikipedia pages tend to get 3x or so improved style recalc time on typical systems with Intel quad core CPUs, for example. Do you have absolute numbers? If it's 100 vs. 300 ms, that'd be huge. If it's 1 vs. 3 ms, I don't really care.
On my Haswell MBP, Stylo can take first pageload styles on Wikipedia pages from 150-200 ms down to 50 ms or so, last I checked.
I wish this post included some benchmarks or measurement.
Just asked Emilio on IRC for some quick numbers. emilio: pcwalton: wrt gecko we have stuff like https://bugzilla.mozilla.org/show_bug.cgi?id=1342220#c25 and similar emilio: pcwalton: there's also the tp6 numbers, though those also measure CSS parsing and other stuff that isn't the style engine per se pcwalton: emilio: our tp6 numbers are improved over Gecko at this point, yes? :) emilio: pcwalton: amazon by a huge am…
http://bholley.net/testcases/style-perf-tests/perf-reftest/b...
Firefox with STYLO_THREADS=1 gets about 160ms on my machine, which is basically parity with safari and chrome. With the parallelism, Firefox gets 40ms. :-)
You can also simulate sequential mode in recent nightlies by ctrl-clicking and loading the tab in the background (we disable parallelism for background loads).
I always wonder, who puts together nifty little blog posts on this kind of thing complete with graphics just for the article? By that I mean, literally what title do they have? Myself and my colleagues would/could write up a technical breakdown of something neat or innovative we might have done to solve some problem at work, but we sure as shit can't make cool little graphics interspersed between opportune paragraphs…