[Bug]: protocol.handle is very slow

[Hill-98]

Preflight Checklist

• [X] I have read the Contributing Guidelines for this project.
• [X] I agree to follow the Code of Conduct that this project adheres to.
• [X] I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

31.0.2

What operating system are you using?

Windows

Operating System Version

Windows 10 LTSC

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

protocol.handle should be close to the speed of reading files natively.

Actual Behavior

protocol.handle is very slow to return some large responses.

Testcase Gist URL

https://gist.github.com/0ad30ffad2209e9021215608d05d9f35

Additional Information

I'm using a custom protocol to serve pages as well as resources, but when I loaded the font files for my application yesterday, I noticed a very serious performance issue. For a 4M font file, Devtools shows that the loading time is 200ms, but I added a timer in protocol.handle and the time does not exceed 10 ms, so I think this is a problem between the main process and the renderer process?

[Hill-98]

This is the download link for the font file: https://drive.google.com/file/d/1ZxHmLE2HWSMk0Yo_Uo0BGGuHkzdUvbiG/view?usp=sharing

[NordlingDev]

I can confirm it's slow for me as well. Similar scenario, but I'm trying to stream a local video file and it takes well over 700ms via protocol but main process says it takes below 100ms only to process the data before sending the response.

[dsanders11]

I've created a simpler gist (does not require manually downloading the font) which repros this issue: https://gist.github.com/dsanders11/346d9f81d512bb1bd43b6bd5417f073a

I've also tested and confirmed that protocol.registerFileProtocol exhibits the same behavior, so it's not specific to protocol.handle. They share the same underlying implementation, so that's not particularly surprising, just making a note of it for future reference.