1568213 - WMFDecoderModule::init() blocks the main thread

Status: RESOLVED FIXED

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

Description

[Mike Conley (:mconley) (:⚙️)]

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

Comment 1

[Shane Caraveo (:mixedpuppy)]

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

Comment 2

[Andrew Swan [:aswan]]

(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?

Comment 3

[Shane Caraveo (:mixedpuppy)]

(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....

Comment 4

[Andrew Swan [:aswan]]

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

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

(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.

Comment 6

[Alastor Wu [:alwu]]

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.

Comment 7

[Andrew Swan [:aswan]]

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.

Comment 8

[Alastor Wu [:alwu]]

This problem no long exists after landing bug 1759033.