New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 700100 link

Starred by 5 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Poor file icon fetching performance on Windows

Reported by biohazar...@gmail.com, Mar 9 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. Download some .exe
2. Close browser
3. Launch browser
4. Open downloads page

What is the expected behavior?
File icons for files appear consistently fast

What went wrong?
Icon fetching performance is inconsistent and might take up to 2s or even more on a performant desktop PC.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 10.0
Flash Version: 

It is not directly affecting chromium, or at least not in really significant way, (just on the downloads page), but the code responsible for icon fetching is pretty slow on windows.
I don't think it is chromium fault, but Windows API used being slow.
The way I got into this issue is via porting(mostly copy-paste) some of the icon fetching code into electron framework.
On Linux, it works perfectly fine, but when running on Windows (on a performant desktop PC), getting 1-2s delay per icon is not uncommon.

Electron PRs:
https://github.com/electron/electron/pull/7851
https://github.com/electron/electron/pull/8704

I'll try to attach some tracing info, but it seems like the issue is in SHGetFileInfo function being slow, and that's a known fact.

 
Components: -Blink>Internals UI>Browser>Downloads
Even msdn says it may be slow.
https://msdn.microsoft.com/en-us/bb761854
Cc: dbeam@chromium.org

Comment 4 by woxxom@gmail.com, Mar 9 2017

Files downloaded from untrusted network zone have a special ADS (alternative NTFS data stream). Windows OS checks such files first by issuing a network request to verify the embedded file certificate in case it's an executable. It also checks file's hashsum. Both these operations take time, there's nothing Chrome can do AFAIK. You can try disabling this Windows feature at your own risk.
Labels: Needs-Triage-M58

Comment 6 Deleted

Attempting to upload trace on behalf of reporter.
trace_Fri_Mar_10_2017_9.40.45_AM.json.gz
2.5 MB Download
Cc: kkaluri@chromium.org
Labels: Needs-Feedback
biohazard707@ could you please respond to comment #4
Where can I find a setting for it?
Project Member

Comment 10 by sheriffbot@chromium.org, Mar 15 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: hdodda@chromium.org
Labels: Needs-Feedback
@biohazard707-- Could you please check as per comment #11 and update the thread.

Thanks!
Yes, as soon as I get to a Windows PC. Sorry for delay.
Project Member

Comment 14 by sheriffbot@chromium.org, Mar 20 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
#11 yes, disabling it speeds it up.
Though I wonder if it is possible to make it fast by default without security tweaks.
Status: WontFix (was: Unconfirmed)
Marking as WontFix for now.  Looks like it's expected behavior for the windows APIs.  Maybe caching icons could fix this?
Cc: dah...@chromium.org
#16 are IExtractIcon APIs subject to this problem too?

Sign in to add a comment