Recently I noticed I was using http://searchfox.org instead of https:// verison of the site. I want to switch, but awesomebar kept giving me the http:// version. To fix this I went in to the history side bar and right-clicked "forget about site" on http://searchfox.org. At this point my browser went completely nuts. It janked hard. Memory usage in the parent spiked to 1GB. One of the child processes (I think extension process, but not sure) went to 3GB. After I could use the browser again I took a memory measurement: 1,033.85 MB (100.0%) -- explicit ├────572.92 MB (55.42%) -- js-non-window │ ├──551.35 MB (53.33%) -- zones │ │ ├──547.09 MB (52.92%) -- zone(0x19ee492a000) │ │ │ ├──454.73 MB (43.98%) ++ strings │ │ │ ├───52.26 MB (05.05%) ++ compartment([System Principal], shared JSM global) │ │ │ ├───24.33 MB (02.35%) ++ shapes │ │ │ └───15.78 MB (01.53%) ++ (26 tiny) │ │ └────4.25 MB (00.41%) ++ (4 tiny) │ ├───16.02 MB (01.55%) ++ runtime │ └────5.56 MB (00.54%) ++ gc-heap ├────161.38 MB (15.61%) -- heap-overhead │ ├──144.70 MB (14.00%) ── bin-unused │ ├───15.92 MB (01.54%) ── bookkeeping │ └────0.75 MB (00.07%) ── page-cache ├─────83.45 MB (08.07%) -- add-ons │ ├──82.11 MB (07.94%) ++ activity-stream@mozilla.org/js-non-window/zones/zone(0x19ee492a000) │ └───1.34 MB (00.13%) -- (13 tiny) │ ├──0.34 MB (00.03%) ++ shield-recipe-client@mozilla.org/js-non-window/zones/zone(0x19ee492a000) │ ├──0.30 MB (00.03%) ++ formautofill@mozilla.org/js-non-window/zones/zone(0x19ee492a000) │ ├──0.16 MB (00.02%) ++ @testpilot-addon/js-non-window/zones/zone(0x19ee492a000)/compartment([System Principal], jar:file:///C:/Users/bkelly/AppData/Roaming/Mozilla/Firefox/Profiles/vrch8i8u.nightly/extensions/@testpilot-addon.xpi!/bootstrap.js) │ ├──0.11 MB (00.01%) ++ firefox@getpocket.com/js-non-window/zones/zone(0x19ee492a000) │ ├──0.09 MB (00.01%) ++ webcompat@mozilla.org/js-non-window/zones/zone(0x19ee492a000) │ ├──0.06 MB (00.01%) ++ presentation@mozilla.org/js-non-window/zones/zone(0x19ee492a000) │ ├──0.05 MB (00.01%) ++ onboarding@mozilla.org/js-non-window/zones/zone(0x19ee492a000) │ ├──0.05 MB (00.01%) ++ screenshots@mozilla.org/js-non-window/zones/zone(0x19ee492a000)/compartment([System Principal], jar:file:///C:/Program%20Files/Nightly/browser/features/screenshots@mozilla.org.xpi!/bootstrap.js) │ ├──0.05 MB (00.00%) ++ webcompat-reporter@mozilla.org/js-non-window/zones/zone(0x19ee492a000) │ ├──0.04 MB (00.00%) ++ aushelper@mozilla.org/js-non-window/zones/zone(0x19ee492a000)/compartment([System Principal], jar:file:///C:/Program%20Files/Nightly/browser/features/aushelper@mozilla.org.xpi!/bootstrap.js) │ ├──0.03 MB (00.00%) ++ flyweb@mozilla.org/js-non-window/zones/zone(0x19ee492a000)/compartment([System Principal], jar:file:///C:/Program%20Files/Nightly/browser/features/flyweb@mozilla.org.xpi!/bootstrap.js) │ ├──0.03 MB (00.00%) ++ followonsearch@mozilla.com/js-non-window/zones/zone(0x19ee492a000)/compartment([System Principal], jar:file:///C:/Program%20Files/Nightly/browser/features/followonsearch@mozilla.com.xpi!/bootstrap.js) │ └──0.02 MB (00.00%) ++ e10srollout@mozilla.org/js-non-window/zones/zone(0x19ee492a000)/compartment([System Principal], jar:file:///C:/Program%20Files/Nightly/browser/features/e10srollout@mozilla.org.xpi!/bootstrap.js) ├─────75.23 MB (07.28%) ── heap-unclassified ├─────53.21 MB (05.15%) ++ window-objects ├─────33.57 MB (03.25%) ++ (22 tiny) ├─────26.89 MB (02.60%) -- workers/workers(chrome) │ ├──21.18 MB (02.05%) -- worker(resource:///modules/sessionstore/SessionWorker.js, 0x19eedec3800) │ │ ├──19.64 MB (01.90%) -- zone(0x19eef893000) │ │ │ ├──18.81 MB (01.82%) ++ strings │ │ │ └───0.84 MB (00.08%) ++ (11 tiny) │ │ └───1.54 MB (00.15%) ++ (3 tiny) │ └───5.71 MB (00.55%) ++ (2 tiny) ├─────13.69 MB (01.32%) ++ storage └─────13.52 MB (01.31%) -- network ├──13.21 MB (01.28%) ++ cache2 └───0.31 MB (00.03%) ++ (5 tiny) Does activity stream do something for every single history change? Does it handle bulk operations when doing "forget this site"?

When removing urls, we notify the removal for each url, and it's likely consumers may want to cleanup data or remove those urls from their caches. It's likely AS is doing some related work. Moreover notifying is also expensive because of how the notifications system works (bug 1340498). Additionally, the History view itself is very inefficiently updating from quite some time, you can find a lot of dupes about history removals being slow. During the 58 cycle we'll work on reintroducing batches in Places views that may help with some of that, plus we are already actively investigating recent regressions in history removals (bug 1376149). All of this to say the whole problem needs a deeper rearchitecting, not just fixing some low hanging fruits. We are trying to do both, but there's a lot to do. We first wanted to remove all the main-thread APIs and then move onto perf of the whole thing, but it's taking time. For Activity Stream, let me set a needinfo on Mardak to verify if there's any simple fixes on their side.

Activity Stream does watch for deletions to trigger its own event to various modules and all content tabs: https://searchfox.org/mozilla-central/source/browser/extensions/activity-stream/lib/PlacesFeed.jsm#39-50 The various modules response by requerying places for new top sites and highlights, so this happens for each page's `onDeleteURI`. Yeah Activity Stream can be smarter with `onBeginUpdateBatch` https://searchfox.org/mozilla-central/source/browser/extensions/activity-stream/lib/PlacesFeed.jsm#59-61

onBeginUpdateBatch is invoked rarely and should not be relied upon.

In particular, the new history API doesn't have the concept of starting and ending a batch. We are evaluating "batching" notifications, but nothing available yet.

From my quick testing of "forget about site" it seems to trigger batch that begins before delete and end after. However, selecting multiple entries from history and deleting them doesn't batch correctly (there is a batch and end, but that's before the onDeleteURIs come). Also, clearing last hour of history does not trigger batch at all. I suppose we can try to fix all cases. Any idea how users usually end up deleting a lot of history?

History > Clear Recent History, and the Forget toolbar button (available from the Customize view) are two other common cases for deleting a lot of history items.

Testing with a copy of my main profile using the Forget button with 24 hours deleting 568 links. Before: total time 1083ms fetchHighlights resource://activity-stream/lib/HighlightsFeed.jsm After: total time 28ms fetchHighlights resource://activity-stream/lib/HighlightsFeed.jsm

(In reply to Ed Lee :Mardak from comment #5) > From my quick testing of "forget about site" it seems to trigger batch that > begins before delete and end after. However, selecting multiple entries from > history and deleting them doesn't batch correctly (there is a batch and end, > but that's before the onDeleteURIs come). Yes, it's all the stuff we need to fix from a long time. Regardless, don't rely on batching notifications if you are implementing optimizations on your side.

Fixed by https://github.com/mozilla/activity-stream/pull/3589 to be uplifted via bug 1403215.