Open Bug 1568213 Opened Last month Updated 20 days ago

WMFDecoderModule::init() blocks the main thread

Categories

(Core :: Audio/Video, enhancement, P2)

Unspecified
Windows
enhancement

Tracking

()

People

(Reporter: mconley, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxperf:p2])

Profile: https://perfht.ml/2Ymf7tV

I'm really unsure of why we might be loading this at all during WebExtension start-up. The following add-ons are installed in this profile:

Adblock Plus - free ad blocker 3.5.2
Cisco Webex Extension 1.4.0
Easy Screenshot 3.67
NoScript 10.6.3
Video DownloadHelper 7.3.6

Whiteboard: [fxperf]
Summary: WebExtension process spends ~2.5 seconds loading up a WMF decoder module for → WebExtension process spends ~2.5 seconds loading up a WMF decoder module

My top guess is Video Downloader. It is probably not lazily loading that module.

Component: General → Developer Outreach

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)

My top guess is Video Downloader. It is probably not lazily loading that module.

This bug isn't in a state where anybody could do meaningful developer outreach. Shane, what are "it" and "that module" in your comment?

Meanwhile, I don't really understand what's happening inside CanCreateMFTDecoder(). Chris, in the profile from comment 0 that function is blocking the main thread (in the extension process) for multiple seconds, is that expected? Is this something that could move off the main thread?

Flags: needinfo?(chris)

(In reply to Andrew Swan [:aswan] from comment #2)

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)

My top guess is Video Downloader. It is probably not lazily loading that module.

This bug isn't in a state where anybody could do meaningful developer outreach. Shane, what are "it" and "that module" in your comment?

"it", referring to the prior sentence, is Video Downloader. "that module" is WMF Decoder per the bug subject. It makes most sense that Video Downloader is using a WMF Decoder, how/why it's using it on startup....

Component: Developer Outreach → General
Priority: -- → P3

I don't think this has anything to do with Video Download Helper or extensions -- here is a different instance where a content process is blocked for over 60 seconds in the same function: https://perfht.ml/2Y0T1xO
I'm not sure what's going on with that content process, in the marker chart there are very long (>60 seconds) events of types FirstNonBlankPaint, DOMContentLoaded, and DocumentLoad all for chrome://gfxsanity/content/sanitytest.html

Type: task → defect
Component: General → Audio/Video
Priority: P3 → --
Product: WebExtensions → Core
Summary: WebExtension process spends ~2.5 seconds loading up a WMF decoder module → WMFDecoderModule::init() blocks the main thread

(In reply to Andrew Swan [:aswan] from comment #2)

Meanwhile, I don't really understand what's happening inside CanCreateMFTDecoder(). Chris, in the profile from comment 0 that function is blocking the main thread (in the extension process) for multiple seconds, is that expected? Is this something that could move off the main thread?

So CanCreateMFTDecoder() will instantiate a decoder the first time it's called for a given decoder type. That will load Windows Media Foundation DLLs from disk, and if the disk is a spinny disk under load, that could be slow. Also, this function does a sync dispatch to an MSCOM MTA thread. So that thread could also be busy.

It's unlikely that the return value of CanCreateMFTDecoder() would change during a session, so potentially the check could be done once in the parent process, and the result propagated to child processes as needed, instead of each child re-running the same checks.

Flags: needinfo?(chris)

According to the comment5, it looks like an enhancement we could have on Windows, not to call CanCreateMFTDecoder every time on the content process, instead, only calling it once on the parent process and propagate it to any child threads need this infomation.

Type: defect → enhancement
OS: Unspecified → Windows
Priority: -- → P2

Just moving this to the parent process would avoid repeating some work, but if we end up blocking the main thread in the parent process, that sounds much worse than the current behavior. I'd be reluctant to pursue that without first having a better understanding of exactly what we're blocked on.

From what I can tell, it looks like we have a single MTA thread named "COM MTA", I think a good next step would be to try to capture a profile that includes that thread so we can get a handle on what's actually going on here. I'll try to do that, but if anybody else beats me to it I won't complain!

Tentatively marking fxperf:p2, this covers the current investigation work, I expect it may change once we zero in on the underlying problem.

Whiteboard: [fxperf] → [fxperf:p2]
You need to log in before you can comment on or make changes to this bug.