1964023 - With sidebar revamp, deleting history items is much slower

Status: NEW

(Firefox :: Sidebar, defect, P2)

Description

[delan azabani [:shuppy]]

I have a large history, with ~109000 rows in moz_places and ~201000 rows in moz_historyvisits.

In the old history sidebar, deleting an item by right clicking and pressing D was immediate, but in the revamped version, it takes over half a second to update after each deletion. This makes it challenging to clean up a bunch of specific items at once.

Comment 1

[Sky Schubert [:skyschub]]

I just looked into this because for me, deleting history items takes ~13 seconds. It's kinda fine if you use the sidebar because there, the deletion is async - but if you use the history window, it completely janks the parent process.

• Profile of the deletion in the sidebar
• Profile of the deletion in the history window

In both cases, I navigated to example.com, then deleted that entry from the history. The profile of the history window is a bit easier to parse, because you can see a solid 13 seconds of jank, and it seems to be executing

SELECT CAST(( strftime('%s','now','localtime','utc') - (SELECT MIN(visit_date)/1000000 FROM moz_historyvisits) ) AS DOUBLE) /86400, strftime('%s','now','localtime','+1 day','start of day','utc') * 1000000

Now, of course, this is an older profile - but lots of Firefox users have old profiles, so I think that shouldn't be too relevant. And I don't even think my profile is that bad - the oldest entry in the history I have is from 2025-11-01, I deleted everything before that. 7 months of somewhat-heavy use shouldn't result in history deletions taking 13 seconds.

Comment 2

[Jens Stutte [:jstutte]]

(In reply to Sky Schubert [:skyschub] from comment #1)

I just looked into this because for me, deleting history items takes ~13 seconds. It's kinda fine if you use the sidebar because there, the deletion is async - but if you use the history window, it completely janks the parent process.

• Profile of the deletion in the sidebar
• Profile of the deletion in the history window

In both cases, I navigated to example.com, then deleted that entry from the history. The profile of the history window is a bit easier to parse, because you can see a solid 13 seconds of jank, and it seems to be executing

SELECT CAST(( strftime('%s','now','localtime','utc') - (SELECT MIN(visit_date)/1000000 FROM moz_historyvisits) ) AS DOUBLE) /86400, strftime('%s','now','localtime','+1 day','start of day','utc') * 1000000

It seems to be waiting for a mutex lock to be able to execute that SQL. Unfortunately your profile did not capture the thread where the work is happening. Could you rerun it after enabling to capture all threads ? There is probably some other slow SQL running that could be interesting to look at for optimization (likely a missing index).

Comment 3

[James Graham [:jgraham]]

Also, I notice that's being called from https://searchfox.org/firefox-main/source/toolkit/components/places/nsNavHistory.cpp#549 which only actually cares if there is at least one day of history (or maybe just one history entry?), which I'd naively assume could be done with some O(1) query (but of course that won't help if we're waiting on a mutex).

Comment 4

[Sky Schubert [:skyschub]]

(In reply to Jens Stutte [:jstutte] from comment #2)

Unfortunately your profile did not capture the thread where the work is happening. Could you rerun it after enabling to capture all threads ?

Sure! Here are profiles with the "all registered threads" checkbox set:

• Sidebar deletion
• History window

Comment 5

[Stuart Colville [:muffinresearch]]

Clearing the priority so this can be re-triaged with the additional information.

Comment 6

[Jens Stutte [:jstutte]]

That seems to point to places.

Comment 7

[:Gijs (he/him)]

I bet Marco knows what's going on here, especially given all the profiles info we now have.

Comment 8

[Marco Bonardo [:mak]]

99% the Library issue is due to running a query on the main-thread while the helper thread is doing heavy SQL I/O. Not a new thing unfortunately, the history/bookmarks views are still executing queries on the main thread. We can move this work to a separate connection to solve this kind of contention, it would still be on the MT but not await for async I/O.

Though, I think the discussion is going off-topic, OP said the new sidebar is slower than the old sidebar, but comment 1 measured the Library. Those are different things (the grouping may be completely different), and while I'd be glad to get a bug on file for the Library contention (please file it!), the sidebar issue must be investigated yet.