See this profile where the main thread was blocked for 1380ms: https://perfht.ml/2qOEzaR 82% of that time is spent in GetFileVersionInfoSizeW, called with this stack: GetFileVersionInfoSizeW GetVersion(wchar_t *) SharedLibraryInfo::GetInfoForSelf() mozilla::Telemetry::GetStackAndModules(std::vector<unsigned int,std::allocator<unsigned int> > const &) `anonymous namespace'::CreateJSHangHistogram `anonymous namespace'::CreateJSThreadHangStats `anonymous namespace'::TelemetryImpl::GetThreadHangStats NS_InvokeByIndex XPCWrappedNative::CallMethod(XPCCallContext &,XPCWrappedNative::CallMode) XPC_WN_GetterSetter(JSContext *,unsigned int,JS::Value *) js::InternalCallOrConstruct(JSContext *,JS::CallArgs const &,js::MaybeConstruct) js::Call(JSContext *,JS::Handle<JS::Value>,JS::Handle<JS::Value>,js::AnyInvokeArgs const &,JS::MutableHandle<JS::Value>) CallGetter GetPropertyOperation Interpret js::RunScript(JSContext *,js::RunState &) assemblePayloadWithMeasurements/payloadObj.threadHangStats<

Markus, do you know about this? Is Core::Gecko Profiler a suitable component for this?

Core::Gecko Profiler is a suitable component for bugs in SharedLibraryInfo, but I think there's not much we can do about it being slow. I think Telemetry should try to call it on a background thread instead.

Moving this work to a background thread will be more involved. We can either: - rework Telemetry ping generation to be in background (hard) - run on-going background tasks to collect the SharedLibraryInfo -> we'd need to confirm that this is "mostly" collecting the data However, this data is only collected when extended Telemetry is on (i.e. for pre-release and opt-in users). I doubt this is high-priority for the current efforts, unless its masking some other issues.

qf- because it doesn't affect release users. Thanks for the explanation in comment 3, Georg!

This should be fixed by bug 1369594