WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED LATER
Bug 17653
CSSRuleSet should be moved out of CSSStyleSelector.cpp into its own files
https://bugs.webkit.org/show_bug.cgi?id=17653
Summary
CSSRuleSet should be moved out of CSSStyleSelector.cpp into its own files
Eric Seidel (no email)
Reported
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.
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2010-11-18 18:37:58 PST
Created
attachment 74337
[details]
Extracted CSSRuleSet.h and CSSRuleSet.cpp
Eric Seidel (no email)
Comment 2
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.
Eric Seidel (no email)
Comment 3
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.
Ryosuke Niwa
Comment 4
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.
Eric Seidel (no email)
Comment 5
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. :)
Ryosuke Niwa
Comment 6
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.
Eric Seidel (no email)
Comment 7
2010-12-20 22:43:57 PST
ping?
Eric Seidel (no email)
Comment 8
2011-05-03 20:23:15 PDT
Looks like this never got landed.
Ryosuke Niwa
Comment 9
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 :(
Eric Seidel (no email)
Comment 10
2011-05-03 20:46:33 PDT
Don't we have perf try-bots these days?
Ryosuke Niwa
Comment 11
2011-11-25 16:13:28 PST
This patch is completely out of date at this point.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug