Open Bug 599980 Opened 14 years ago Updated 3 months ago

favicon protocol handlers could use a cloned read-only connection

Categories

(Toolkit :: Places, defect, P3)

defect
Points:
5

Tracking

()

People

(Reporter: sdwilsh, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [snt-scrubbed][places-performance][favicons-2024])

User Story

We'd like to use a read-only cloned connection to fetch favicons from the page-icon and cached-favicon protocol, that will avoid any contention with database writers.
Though, we already have 2 RO clones in PlacesUtils, a generic one and a large cache one (used by the urlbar).
We also have a clone in History for link coloring (see https://searchfox.org/mozilla-central/rev/01aaa47e62a2015e7641f26ab0bc2bb00ab579b8/toolkit/components/places/History.cpp#1504,1511,1515).
Adding a further RO connection may not be advisable, as it would also increase memory usage.
We could instead move the History RO connection to the main Database object, make it more generic, and reuse it for both link coloring and favicons. We probably want to keep the prepared statements along with the connection, while the mVisitedQueries can stay in a History class. Shutdown may require some adjustement.
We should stop having lock contention and let the annotation protocol use it's own read-only database connection. Also means less stuff happening on primary connection's background thread. Bonus: with WAL (bug 573492) it means writers and readers can happen at the same time. Parallelism FTW.
Priority: -- → P3
Keywords: perf
Summary: Annotation/favicon protocol handler should use a cloned read-only connection → favicon protocol handlers could use a cloned read-only connection
Severity: normal → S3
Whiteboard: [snt-scrubbed][places-performance]
Duplicate of this bug: 1352012
Whiteboard: [snt-scrubbed][places-performance] → [snt-scrubbed][places-performance][favicons-2024]
User Story: (updated)
Points: --- → 5
You need to log in before you can comment on or make changes to this bug.