Attaching a trace file.
FaviconCache::GetFaviconInfo() allocates 150KB.
GetImageDataFromSpecifics allocates 50KB.

Deleted: trace_bookmark_test3.json 9.1 MB

trace_bookmark_test3.json 9.1 MB View Download

ssid@: How easy is it to detect that we are running on low end device?

You can just call SysInfo::IsLowEndDevice().

What're the user-facing implications of removing the favicon cache? Will the favicons in the bookmark manager just take longer to load, since they'll have to be fetched from disk?

This only affects favicons in the history page/recent tabs. Bookmarks will continue to work fine.

And the effect would be that favicons would just take longer to load, not that they wouldn't be there at all, correct?

They would only load if the device had been to that same page. If the page was only visited on a foreign device, the favicon would just not load I believe.

+Peter, as there has also been some work about fetching of favicons automatically on the device. Although I don't think that's done yet?

Fetching favicons on demand for Zine has been implemented by mastiz@ and jkrcal@
There were discussions about expanding the fetching on demand for chrome://settings on the desktop (passwords and search engines) but no one has stepped up to do that work (I haven't stepped up either)

We should probably just get rid of the favicons datatype at this point, but leaving this open for the MUC handoff.

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.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot