Bugzilla

(In reply to Florian Quèze [:florian] from comment #7)
> Unfortunately the glean.dispatcher thread doesn't seem to be registered with the profiler, so I don't know what it was doing. 

bug 1899618 might now have enough information on it to be actionable, pending bandwidth. Though comment 5 suggests a problem with Fenix that we haven't looked into in a long while.
 
(In reply to Florian Quèze [:florian] from comment #8)
> Chris, anything we can do to reduce the overhead of these glean metrics? https://share.firefox.dev/4k01B4T

Wow, that's a lot of `0ns` samples. Good, I guess, but a bit much to dispatch for every sample, I agree.

Yeah, actually, we have in Rust [a buffered API for `*_distribution` metrics](https://mozilla.github.io/glean/book/reference/metrics/timing_distribution.html#startbuffer) (bug 1916673). We'd need to first implement the FOG Rust API for it (as an experimental API, we've only been adding support as it's been requested (`memory_distribution` and `custom_distribution` support was added in  bug 1919245). And then we'd need to design and implement the C++ API atop it so that `nsSocketTransportService2.cpp` can use it. (Lucky us: all the markers in your profile are parent-process. If this can sometimes be child-process, we'll need to figure out IPC as well (bug 1920957))

(In reply to Florian Quèze [:florian] from comment #7)
> Unfortunately the glean.dispatcher thread doesn't seem to be registered with the profiler, so I don't know what it was doing. 

bug 1899618 might now have enough information on it to be actionable, pending bandwidth. Though bug 1899618 comment 5 suggests a problem with Fenix that we haven't looked into in a long while.
 
(In reply to Florian Quèze [:florian] from comment #8)
> Chris, anything we can do to reduce the overhead of these glean metrics? https://share.firefox.dev/4k01B4T

Wow, that's a lot of `0ns` samples. Good, I guess, but a bit much to dispatch for every sample, I agree.

Yeah, actually, we have in Rust [a buffered API for `*_distribution` metrics](https://mozilla.github.io/glean/book/reference/metrics/timing_distribution.html#startbuffer) (bug 1916673). We'd need to first implement the FOG Rust API for it (as an experimental API, we've only been adding support as it's been requested (`memory_distribution` and `custom_distribution` support was added in  bug 1919245). And then we'd need to design and implement the C++ API atop it so that `nsSocketTransportService2.cpp` can use it. (Lucky us: all the markers in your profile are parent-process. If this can sometimes be child-process, we'll need to figure out IPC as well (bug 1920957))

(In reply to Florian Quèze [:florian] from comment #7)
> Unfortunately the glean.dispatcher thread doesn't seem to be registered with the profiler, so I don't know what it was doing. 

bug 1899618 might now have enough information on it to be actionable, pending bandwidth. Though bug 1899618 comment 5 suggests a problem with Fenix that we haven't looked into in a long while.
 
(In reply to Florian Quèze [:florian] from comment #8)
> Chris, anything we can do to reduce the overhead of these glean metrics? https://share.firefox.dev/4k01B4T

Wow, that's a lot of `0ns` samples. Good, I guess, but a bit much to dispatch for every sample, I agree.

Yeah, actually, we have in Rust [a buffered API for `*_distribution` metrics](https://mozilla.github.io/glean/book/reference/metrics/timing_distribution.html#startbuffer) (bug 1916673). We'd need to first implement the FOG Rust API for it (as an experimental API, we've only been adding support as it's been requested (`memory_distribution` and `custom_distribution` support was added in  bug 1919245)). And then we'd need to design and implement the C++ API atop it so that `nsSocketTransportService2.cpp` can use it. (Lucky us: all the markers in your profile are parent-process. If this can sometimes be child-process, we'll need to figure out IPC as well (bug 1920957))