> I'm assuming that you're talking about nsStyleContext lazily > computing the results of GetStyle*() when those functions are called > rather than computing it at the time the style context is created > (which is itself buffered up in ways that are very important).
Indeed. > Off the top of my head, I think the biggest reason for this is that > it's probably a bit of a savings in memory use, since there are a > bunch of structs that we won't create for many elements -- though as > bz said, I'm not sure how true that is anymore. That makes perfect sense, but what isn't immediately clear to me is whether there are any cases where an eager CSS implementation couldn't determine in advance that a given style struct wouldn't be needed. If so, laziness is just an implementation strategy for this optimization and not a requirement. > What would the advantage of computing them eagerly be? That is a bit hard for me to answer right now as I don't yet have a good mental model of Gecko's CSS and layout subsystems, but it might be that computing them eagerly could be made more efficient. For example: - We might be able to better overlap eager style computations with IO. - Eager style computations might have better locality characteristics. - We might be able to use a different, more efficient algorithm. - We might be able to better take advantage of parallelism. - Eager style computations might yield code that is easier to understand. I've seen cases where all of these "might"s have been true on other projects I've worked on; sometimes there are substantial costs to laziness, even if it's more work efficient. They're not always true, and right now I can't say whether the tradeoffs favor laziness in this case or not, but I do think it's something worth thinking about. Thanks, - Seth _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
