1533061 - browser.bookmarks.create is orders of magnitude slower than on Chromium

Status: NEW

(Toolkit :: Places, defect, P3)

Description

[nero120]

The creation of bookmarks in Firefox using the browser.bookmarks API is painfully slow, many orders of magnitude slower than the equivalent code running in Chromium.

To demonstrate this, run the following code which times the creation of a large number of bookmarks in the console of an extension with "bookmarks" permissions:

On Chromium:

let bookmarks = [];
for (i = 0; i < 10000; i++) {
	let result = bookmarks.push({ title: `${i + 1}`, url: `https://www.google.co.uk/search?q=${i + 1}` });
}
let startTime = new Date();
let createBookmarks = Promise.all(bookmarks.map(bookmark => {
	return new Promise(resolve => {
		chrome.bookmarks.create(bookmark, resolve);
	});
}))
	.then(() => {
		let endTime = new Date();
		let timeTaken = (endTime - startTime) / 1000;
		console.log(`10,000 bookmarks took ${timeTaken}s to be created.`);
	});

Result: 10,000 bookmarks took 2.551s to be created.

On Firefox:

let bookmarks = [];
for (i = 0; i < 10000; i++) {
	let result = bookmarks.push({ title: `${i + 1}`, url: `https://www.google.co.uk/search?q=${i + 1}` });
}
let startTime = new Date();
let createBookmarks = Promise.all(bookmarks.map(bookmark => browser.bookmarks.create(bookmark)))
	.then(() => {
		let endTime = new Date();
		let timeTaken = (endTime - startTime) / 1000;
		console.log(`10,000 bookmarks took ${timeTaken}s to be created.`);
	});

Result: 10,000 bookmarks took 335.302s to be created.

So Firefox took nearly six minutes to create 10,000 bookmarks compared to Chromium's 2.5 seconds!!! What is causing Firefox to be so slow?

Comment 1

[Mark Banner (:standard8)]

Did you either of the bookmarks toolbar / library window open whilst running this code?

Additionally, what's the use-case for creating lots of bookmarks at one time in this fashion? Most user have less than 2000 bookmarks, so that's generally the main cases we prioritise for.

One of the problems here is that as create is doing a single bookmark at a time, that's going to give a lot more overhead for our database operations than if we were able to do that in bulk. Not sure what we can do about that though.

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I suspect most of the time is spent in frecency re-calc.
We can surely do some profiling.

Comment 3

[nero120]

(In reply to Mark Banner (:standard8) from comment #1)

Did you either of the bookmarks toolbar / library window open whilst running this code?

Additionally, what's the use-case for creating lots of bookmarks at one time in this fashion? Most user have less than 2000 bookmarks, so that's generally the main cases we prioritise for.

One of the problems here is that as create is doing a single bookmark at a time, that's going to give a lot more overhead for our database operations than if we were able to do that in bulk. Not sure what we can do about that though.

Yes initially the bookmarks window was open. After running the same example code without opening the bookmarks window it took ~3.5 minutes to complete, less time but still completely unacceptable from a user standpoint.

My extension populates bookmarks, some users have upwards of 10,000 bookmarks but the average is probably a few thousand. Regardless, the difference in populating 2,000 bookmarks almost instantianiously in Chrome, compared to it taking nearly 30 seconds in Firefox is stark, and users have raised it with me as an issue.

If you are going to provide an API then clearly it makes sense for that API to be performant when compared to the competition. In this regard, Firefox is lagging so far behind Chrome that it isn't even on the same planet...

Comment 4

[nero120]

(In reply to Marco Bonardo [::mak] from comment #2)

I suspect most of the time is spent in frecency re-calc.
We can surely do some profiling.

Thank you Marco that is most appreciated.

Comment 5

[olejorgenb]

+1. As a user of the tab-stash extension I strongly suspect this issue is at least partially responsible for the bad performance.

Comment 6

[Mark Banner (:standard8)]

This really needs bug 1818458 fixing first and then re-checking afterwards.

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

A new profile after recent improvements: https://share.firefox.dev/48hbFR2
Time is shorter (99s) but still excessive, it looks like it's just a huge backlog list we go through one by one, and we do disk I/O at each step.
The Chrome approach, afaik, is to store bookmarks in a memory object and then periodically write them down to disk, that is likely what explains the huge remaining difference here.