On 6/13/13 5:48 PM, Joel Feenstra wrote:
I thought inline attributes had to be added to things. Maybe that was a while
ago.
They do to get cross-crate inlining to work. That's by design, so that
you can replace the bodies of non-inlined functions without having to
recompile all downstream cr
I thought inline attributes had to be added to things. Maybe that was a while
ago.
On Jun 13, 2013, at 8:46 PM, Patrick Walton wrote:
> On 6/13/13 5:45 PM, Joel Feenstra wrote:
>> What about an enum of the various style lookup strategies with
>> inlining for all of them. Rustc/LLVM may need to
On 6/13/13 5:45 PM, Joel Feenstra wrote:
What about an enum of the various style lookup strategies with
inlining for all of them. Rustc/LLVM may need to be able to inline 2
levels of function calls (to call the enum impl and then the value
impl), and I know it isn't great at inlining currently.
> OK. So in Gecko, we get styles a _lot_; the performance of the calls is
> definitely very noticeable (e.g. having them inlined helps a lot).
I see, if any sort of function call is too expensive (inlining is required)
then lots of conditionals may be the only option to avoid storing the styles
On 6/13/13 9:56 AM, Joel Feenstra wrote:
Peformance is a good question. My guess would be that it'd perform
somewhere between a virtual function and plain function call. I'd
definitely want to run some numbers to know for sure, but it's not much
different from using function pointers in C (as far
Peformance is a good question. My guess would be that it'd perform
somewhere between a virtual function and plain function call. I'd
definitely want to run some numbers to know for sure, but it's not much
different from using function pointers in C (as far as I understand rust
anyway).
- Joel
On
On 6/12/13 6:06 PM, Joel Feenstra wrote:
What if the boxes and flow contexts were given a style accessor closure by
the box/flow builder.
How well would this perform? At least in Gecko, getting styles is
something that happens a _lot_ and is a notorious performance hotspot
during layout...
What if the boxes and flow contexts were given a style accessor closure by
the box/flow builder. Presumably the builder would need those styles
anyway, and they could point to any part of the style tree or have any
filtering or whatever as necessary. That way we wouldn't need special types
of boxes
It looks like in servo we're basically trying to have styles live on
elements, with no concept of a "style" attached to layout boxes or flows
at all. Anyone who needs styles has to talk to the element.
This works pretty well (and makes things like style recomputation much
simpler) except when
9 matches
Mail list logo
