Open Bug 1216272 Opened 9 years ago Updated 2 years ago

Use transactions in history sync

Categories

(Firefox for iOS :: Sync, defect)

Product:
Firefox for iOS
Component:
Sync
Platform:
All
iOS
Type:
defect

Tracking

()

People

(Reporter: rnewman, Unassigned, Mentored)

References

(Depends on 1 open bug)

Details

(Keywords: perf)

Similar to Bug 1178585. If you run a first sync with the right log levels, you'll see a bunch of work being done: 2015-10-19 12:42:33.197 [Debug] [HistorySynchronizer.swift:172] synchronizeLocalHistory(_:withServer:info:) > Records header hint: Optional(38) 2015-10-19 12:42:33.198 [Debug] [SwiftData.swift:126] transaction > Op in transaction succeeded. Committing. 2015-10-19 12:42:33.201 [Debug] [SwiftData.swift:126] transaction > Op in transaction succeeded. Committing. 2015-10-19 12:42:33.203 [Debug] [SwiftData.swift:126] transaction > Op in transaction succeeded. Committing. 2015-10-19 12:42:33.205 [Debug] [SwiftData.swift:126] transaction > Op in transaction succeeded. Committing. … 2015-10-19 12:42:33.428 [Debug] [IndependentRecordSynchronizer.swift:41] done() > Bumping fetch timestamp to 1445283746540. We should use coarse-grained transactions to add a bunch of history items without committing in between. This is currently difficult because of the callback-oriented approach that SwiftData takes to transactions. There are some other TODOs in the code that will make this more efficient, including batching up non-present history items to insert with a single INSERT. Combining this with Bug 1168856 will make big history syncs more efficient and less likely to gum up the browser for extended periods of time.
Depends on: 1189170
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.