Large hangs (4.1s) when navigating caused by having Library open with a search
Categories
(Toolkit :: Places, defect, P3)
Tracking
()
People
(Reporter: jrmuizel, Unassigned)
References
(Depends on 2 open bugs)
Details
(Keywords: perf, stalled)
Attachments
(1 obsolete file)
STR:
- Open Library and enter a search
- Navigate in Gmail
See https://share.firefox.dev/3roVt0I
Note, I have:
places.history.expiration.max_pages = 999999
places.history.expiration.transient_current_max_pages = 9999999
so most people probably don't have it as bad as me, but I find I expect having the defaults there won't get time in nsNavHistory::GetQueryResults down below 16ms
Comment 1•1 year ago
|
||
The severity field is not set for this bug.
:mak, could you have a look please?
For more information, please visit BugBot documentation.
Comment 2•1 year ago
|
||
This is unfortunately "expected", and it's one of the reasons for which we limit the number of pages.
It's due to a series of architectural problems that we didn't address yet:
- Places views query on the main thread. Firefox View may potentially be a new async history view. We're also working to remove any non-refreshing query so that moving the queries off the main thread will be easier in the future, though we must figure out how to handle pending updates in the UI.
- We search for strings linearly (row by row), we can't use an index, because we don't have one. In this case the open query has a search string, a visited page changes title, and we must check if the query results may change. We're experimenting with full text indices yet due to localization concerns. An index would likely reduce this to milliseconds.
In this specific case, the search string matches the title of the newly added page, so we must update the query results. Doing an incremental update may add quite some complexity, so we just refresh the whole results. That's usually fast, but not if the database has to examine 900k rows and match a search string per each row.
While we're working on both issues, there's currently no ETA as some of the changes require experimentation and this refactoring it not our primary target of development (it's part of the 20% other stuff we're working on).
Updated•11 months ago
|
Updated•9 months ago
|
Description
•