loading multiple images from blob gets stalled
Reported by
pda...@gmail.com,
Jan 29 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. load a lot of images using blob and createObjectURL What is the expected behavior? faster loading then base64 encoded images What went wrong? Its really weird, and i assume the issue occurs because of a lock on the cache hit test. As it seems, since createObjectURL creates a url from the blob, a cache hit test happens. the cache test locks and creates a stall on all other loading threads. Loading using base64 does not test the cache and loads faster even though a "base64 decode" is required. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 55.0.2883.87 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 24.0 r0 the attached test.html shows loading time for the same image 1000 times once using base64 and once using blobs. attached values from chrome firefox and edge for the provided test.html.
,
Jan 30 2017
,
Feb 1 2017
,
Feb 3 2017
Confirmed with Chrome 58 (canary) on Fedora 25 and OSX 10.12.2. Worth noting -- On OSX, I get a better time (~300, as opposed to ~100 for base64) for Blob on about 20% of "Blob" button clicks. On Linux, I get a better time (~300 as opposed to ~200) on about 30% of "Blob" button clicks. I'm not surprised that the Blob case takes longer. We probably have a fast path for using base64 as image URLs. Building a blob and minting a URL require browser-wide coordination, and this was optimized for large amounts of data. That being said, we should probably understand exactly what's happening here before we WontFix the bug. dmurph: I cc-ed you so you can take a look at this if you're interested.
,
Feb 4 2017
I can confirm occasional ~300ms timings on windows as wellׄ Why do you expect this to be a "WontFix" situation?
,
Feb 12 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 12 2018
Yeah, if you already have the data in memory (base64 encoded even) in javascript/the renderer, just loading from a data url is always going to be way faster than creating a blob (sync IPC), sending all the data to the browser process, creating a blob URL (another sync IPC), and finally reading all the data back into the renderer. Ad of course, the data URL test uses the same URL for every request, while for the blob URL case you are creating a fresh URL for every new request. That probably/possibly even means that in the data URL case you're only actually loading/decoding the image once, and all the rest is just using the already decoded image. So yes, there might be some room for improvement in the blob case (we can at least ultimately change one of the sync IPCs into async), but the test as written I would expect data URLs to always win.
,
Jun 15 2018
,
Jun 15 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by pda...@gmail.com
, Jan 29 201710.5 KB
10.5 KB View Download