Bug 17653 - CSSRuleSet should be moved out of CSSStyleSelector.cpp into its own files
Summary: CSSRuleSet should be moved out of CSSStyleSelector.cpp into its own files
Status: RESOLVED LATER
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 49775
  Show dependency treegraph
 
Reported: 2008-03-03 14:26 PST by Eric Seidel (no email)
Modified: 2011-11-25 16:13 PST (History)
4 users (show)

See Also:


Attachments
Extracted CSSRuleSet.h and CSSRuleSet.cpp (24.70 KB, patch)
2010-11-18 18:37 PST, Ryosuke Niwa
eric: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-03-03 14:26:25 PST
CSSRuleSet should be moved out of CSSStyleSelector.cpp into its own files

I went looking for CSSRuleSet today, and found it wasn't in its own file(s).  It would be nice to see it moved.
Comment 1 Ryosuke Niwa 2010-11-18 18:37:58 PST
Created attachment 74337 [details]
Extracted CSSRuleSet.h and CSSRuleSet.cpp
Comment 2 Eric Seidel (no email) 2010-11-18 20:17:43 PST
Do we have a good way to performance test this?

It would be awesome if we could make a CSSStyleSelector micro-benchmark like we have for the html-parser (in WebCore/benchmarks).

It's possible this could cause some of these functions to not inline, which could slow down.  I'm not super concerned, but we just need to make sure we know we're going to catch a problem if this were to regress.
Comment 3 Eric Seidel (no email) 2010-11-18 20:19:09 PST
Comment on attachment 74337 [details]
Extracted CSSRuleSet.h and CSSRuleSet.cpp

View in context: https://bugs.webkit.org/attachment.cgi?id=74337&action=review

LGTM, assuming you're not changing any logic (just moving) and you have an answer for the perf question.

> WebCore/css/CSSRuleSet.cpp:43
> +: m_ruleCount(0)
> +, m_pageRuleCount(0)

I think we normally indent these.
Comment 4 Ryosuke Niwa 2010-11-18 21:07:08 PST
(In reply to comment #2)
> Do we have a good way to performance test this?

No.  Maybe we need to make a benchmark.

> It would be awesome if we could make a CSSStyleSelector micro-benchmark like we have for the html-parser (in WebCore/benchmarks).

> It's possible this could cause some of these functions to not inline, which could slow down.  I'm not super concerned, but we just need to make sure we know we're going to catch a problem if this were to regress.

Right.  jamesr pointed that out as well.

(In reply to comment #3)
> LGTM, assuming you're not changing any logic (just moving) and you have an answer for the perf question.

We need to figure out how to perf-test this.
Comment 5 Eric Seidel (no email) 2010-11-18 21:40:17 PST
It's possible a sufficient answer to the perf question is that the PLT (which I believe chromium runs automatically on some bots) doesn't slow down.  But if you were to come up with a micro benchmark that might be even better. :)
Comment 6 Ryosuke Niwa 2010-11-19 10:08:02 PST
(In reply to comment #5)
> It's possible a sufficient answer to the perf question is that the PLT (which I believe chromium runs automatically on some bots) doesn't slow down.  But if you were to come up with a micro benchmark that might be even better. :)

Why don't we make the constructor, destructor, and addPageRule inline?  Other functions are too big to be inlined or the cost of not being inline is negligible.  James said inlining might hurt the performance as well but I'm almost certain that the compiler won't keep it inline if that's the case.
Comment 7 Eric Seidel (no email) 2010-12-20 22:43:57 PST
ping?
Comment 8 Eric Seidel (no email) 2011-05-03 20:23:15 PDT
Looks like this never got landed.
Comment 9 Ryosuke Niwa 2011-05-03 20:39:09 PDT
(In reply to comment #8)
> Looks like this never got landed.

Yeah, I never got around to test the performance :(
Comment 10 Eric Seidel (no email) 2011-05-03 20:46:33 PDT
Don't we have perf try-bots these days?
Comment 11 Ryosuke Niwa 2011-11-25 16:13:28 PST
This patch is completely out of date at this point.