Closed
Bug 713031
Opened 13 years ago
Closed 7 years ago
Add CSS selector profiler
Categories
(DevTools :: Performance Tools (Profiler/Timeline), defect)
DevTools
Performance Tools (Profiler/Timeline)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: kangax, Unassigned)
Details
Attachments
(2 files)
Something similar to http://my.opera.com/dragonfly/blog/style-profiler-preview from Opera or https://bugs.webkit.org/show_bug.cgi?id=74004 from WebKit.
AFAIK, there's currently no way to see how much time is spent on evaluating certain CSS rule, and how much time is spent on document reflow and/or repaint.
Reporter | ||
Updated•13 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 1•13 years ago
|
||
A generic profiler would be great, but a CSS selector profiler would also be very useful.
Comment 2•13 years ago
|
||
This needs a feature page.
Comment 3•13 years ago
|
||
kdangoor, would you like to do the honors or should I?
Updated•11 years ago
|
Flags: needinfo?(dangoor)
Comment 4•11 years ago
|
||
I don't believe anyone uses feature pages in Mozilla any longer. I suppose mockups, user stories and the like are still needed, but that's a task for whoever starts working on this issue.
Flags: needinfo?(dangoor)
Comment 5•11 years ago
|
||
Opera's old style profiler
Comment 6•11 years ago
|
||
I'm going to work on this in bug 975522.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Is bug 975522 really a duplicate of this? That one seems to just cover "was a selector used or not", while this is about time spent per selector. But maybe you plan to add more than what the description and existing patch over there conveys...? :)
Flags: needinfo?(jwalker)
Comment 8•11 years ago
|
||
(In reply to J. Ryan Stinnett [:jryans] from comment #7)
> Is bug 975522 really a duplicate of this? That one seems to just cover "was
> a selector used or not", while this is about time spent per selector. But
> maybe you plan to add more than what the description and existing patch over
> there conveys...? :)
No, thanks - it's not a dupe of this. I'm fairly sure, bug 834865 is what I was thinking of.
Status: RESOLVED → REOPENED
Flags: needinfo?(jwalker)
Resolution: DUPLICATE → ---
Updated•9 years ago
|
Component: Developer Tools → Developer Tools: Performance Tools (Profiler/Timeline)
Version: 12 Branch → Trunk
Comment 9•7 years ago
|
||
julien, markus: is this idea still worth keeping around, or re-filing new bugs that are actionable? The links are pretty stale to the ideas.
Flags: needinfo?(mstange)
Flags: needinfo?(felash)
Comment 10•7 years ago
|
||
I think we should re-file new bugs. I'm not even sure the tool for this should live in the profiler. Maybe it should be next to selectors in the inspector.
Ideas come and go, and are only implemented when we have the right project/opportunity. It rarely is useful to keep old futuristic ideas in bugzilla. We very rarely end up implementing them as such.
Comment 11•7 years ago
|
||
Knowing the performance characteristics of some CSS selectors are useful in some constrained environment. Especially I like the view from attachment 8404807 [details].
However I believe the performance problems of CSS selectors were often fantasized. When this starts to be an issue it also usually means you have other problems: a lot of selectors in the first place, long selectors, etc. I think it's easy to spot without a tool.
Furthermore I think that in nowadays' landscape the performance of an app's CSS is much less important than the performance of an app's JavaScript code.
That said we should likely make it more obvious that "RefreshStyles" is about applying CSS to the DOM. Is it already obvious in our Devtools Performance panel ?
Flags: needinfo?(felash)
Comment 12•7 years ago
|
||
Let's go ahead and close this as it's not actionable, and we're tracking product work elsewhere.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 7 years ago
Flags: needinfo?(mstange)
Resolution: --- → WONTFIX
Comment 13•7 years ago
|
||
(In reply to Greg Tatum [:gregtatum] [@gregtatum] from comment #12)
> Let's go ahead and close this as it's not actionable, and we're tracking
> product work elsewhere.
Would be good if you pointed the followers of this bug were product work is being tracked.
I believe something like this would fit perfectly into the audit mode covered in bug 1415357, but sure, it needs to be discussed first how this feature should look like.
Sebastian
Comment 14•7 years ago
|
||
Performance work is tracked either in perf.html or the Gecko profiler:
https://github.com/devtools-html/perf.html
https://bugzilla.mozilla.org/buglist.cgi?cmdtype=runnamed&namedcmd=gecko-profiler&list_id=14006296
Further venues for communication can be found at: http://firefox-dev.tools/
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•