Closed Bug 1505908 Opened 4 years ago Closed 3 years ago

Give stylo rust code the ability to push and pop profiler label frames


(Core :: CSS Parsing and Computation, enhancement, P3)




Tracking Status
firefox65 --- wontfix
firefox68 --- fixed


(Reporter: mstange, Assigned: heycam)


(Blocks 1 open bug)



(1 file)

Bug 1500692 is adding subcategory support for profiler label frames, but those currently can't be used from rust code, which is unfortunate, see :

> Adding separate labels for property cascading / selector matching / style
> invalidation would be useful, though those are on the rust side, so not sure
> how easy to add they are. Is there any plan to add profiler support to rust
> code?

This bug is about adding this capability.

I'm not sure how it should be done. Should we expose the full category enum to rust? How should we set up the bindings to do the actual pushing and popping of the profiler labels? Should those be callback functions which are registered dynamically by Gecko during Stylo initialization?
Bindgen already understands enums and such for a lot of Gecko code, and runs after the export phase, so getting the enums there may not be the biggest issue...

If adding some FFI functions for the profiler to push and pop is not too hard, I'm happy to take a look and hook the bindings up.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)
> If adding some FFI functions for the profiler to push and pop is not too
> hard, I'm happy to take a look and hook the bindings up.

Here's what Gecko's RAII object for profiler labels does:,822-855
Should be simple enough to wrap in binding functions.
Over to the queue :)
Flags: needinfo?(emilio)
Priority: -- → P3

I have a patch for this. The one concern I have is that this does the profiler label push/pop for every Rayon work item. I haven't yet measured to see whether that's a lot of overhead. The alternative might be to do the push/pop down inside rayon::registry::wait_until_cold, but that's a bit less general as we really do have different kinds of work happening on the style threads -- style computation or CSS parsing. Though which category it is should be constant for a given rayon::Scope.

It's around 280 ns of overhead when styling is in full flight, which should be acceptable.

Pushed by
Add Gecko profiler labels for when the style threads are doing work. r=emilio
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Assignee: nobody → cam
Blocks: 1551761
Flags: needinfo?(emilio)
You need to log in before you can comment on or make changes to this bug.