Open Bug 1685140 Opened 5 years ago Updated 1 years ago

Noticeable UI lag when deleting lots of history entries because TopSitesFeed.refresh is called for every single one

Categories

(Firefox :: Top Sites, defect, P3)

defect

Tracking

()

Performance Impact low

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: perf, perf:frontend, perf:responsiveness)

Attachments

(1 file)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0 ID:20210104172545

Here a profile with a recent Nightly that shows that certain Activity stream related code is running on the main thread and causing event processing delays:

https://share.firefox.dev/3pXH9Gp

Note that this happened after I tried to remove all traces for a site via the history sidebar, which blocked the Firefox UI for nearly 80s (see bug 1458634).

Flags: needinfo?(sdowne)

Do you think this might be a recent regressions?

Are you able to reproduce the jank consistently?

I got some help looking the perf profile, and it looks like a lot of this is happening in TopSitesFeed.getLinksWithDefaults so I think maybe moving this to the topsites component might be better.

Flags: needinfo?(sdowne) → needinfo?(hskupin)

I got it twice so far by trying to restore a local Firefox profile, which then get synced with Firefox accounts. Whereby the sync steps removed a lot of history items. I don't care which component that is in. So feel free to do what you think is best.

Flags: needinfo?(hskupin)

Alright, going to try it in topsites component, and see if that helps. It might come back to newtab and that's fine.

Component: New Tab Page → Top Sites
Severity: -- → S3
Depends on: 1458634, 734643
Priority: -- → P3
Summary: Noticeable UI lags because Activity stream code runs on MainThread → Noticeable UI lag when deleting lots of history entries because TopSitesFeed.refresh is called for every single one
Depends on: 1678618
No longer depends on: 1458634
Depends on: 1473529
No longer depends on: 734643
See Also: → 734643
Whiteboard: [fxperf] → [fxperf:p3]

(In reply to Scott [:thecount] Downe from comment #2)

Do you think this might be a recent regressions?

Are you able to reproduce the jank consistently?

I got some help looking the perf profile, and it looks like a lot of this is happening in TopSitesFeed.getLinksWithDefaults so I think maybe moving this to the topsites component might be better.

Never digged into this, but I've seen this for a long time (probably since Firefox 50s or 60s versions).

I delete cache and cookies on a regular basis, but keep the browsing history usually for a couple of months. When deleting a web site with a small number of page visits deletion is fast, but when there are more entries (> 500) it takes minutes. I've attached a screenshot deleting my ebay.de history. It had about 600 subentries and took 4 minutes. Also notice I/O total rate that ProcessHacker reports (> 1GB).

Attached image firefox.png
Performance Impact: --- → low
Whiteboard: [fxperf:p3]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: