Firefox/Projects/Places Expiration Performance Refactoring: Difference between revisions
Jump to navigation
Jump to search
Comrade693 (talk | contribs) (→Design) |
m (moved Firefox/Sprints/Places Expiration Performance Refactoring to Firefox/Projects/Places Expiration Performance Refactoring: They're actually projects) |
||
| (5 intermediate revisions by 4 users not shown) | |||
| Line 8: | Line 8: | ||
= Goals / Use Cases = | = Goals / Use Cases = | ||
* Continue to reduce the number of writes and fsyncs that we perform | * Continue to reduce the number of writes and fsyncs that we perform | ||
* Move resource intensive activity off of the UI thread for improved snappiness | |||
* Simplify expiration code | * Simplify expiration code | ||
| Line 21: | Line 22: | ||
= Bugs = | = Bugs = | ||
{{bug|480211}} | |||
Latest revision as of 22:16, 7 August 2009
Overview
Sprint lead: sdwilsh
Sprinters: marco, dietrich
- Description
- Reduce code complexity and increase performance by reducing writes we do shortly after visiting a page.
Goals / Use Cases
- Continue to reduce the number of writes and fsyncs that we perform
- Move resource intensive activity off of the UI thread for improved snappiness
- Simplify expiration code
Non Goals
- Completely change our expiration algorithm (only looking for a small improvement)
Design
Current theory is to expire whenever we do a timed flush in nsPlacesDBFlush.js. The idea is to expire some entries first, before we flush the temporary tables to disk, so we can free up disk space that can be reclaimed by the flush.
In order to notify observers properly, we'll first run a select query (asynchronously) to obtain the uri and visit time. We then expire those visits (and only the visits), and perform the normal flush queries.
In order to notify observers, we'll be creating a special object to pass to nsINavHistory::runBatched that contains the information we care about for notifications.