User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.6) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6 Build Identifier: Firefox Sync 1.4 on Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.6) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6 Firefox becomes completely unresponsive (not even the window is redrawn) for a couple of minutes during sync. In verbose-log.txt this would be between 2010-07-02 09:23:32 Engine.Bookmarks INFO Records: 0 applied, 0 reconciled, 0 left to fetch 2010-07-02 09:26:37 Engine.Bookmarks INFO Uploading all of 11 records There do not appear to be any errors in the syncing and it completes successfully. This may therefore be "standard" behaviour which only becomes annoyingly noticeable on fairly slow machines and with large numbers of bookmarks (in my case, over 6000). However, as far as I recall, this problem was absent before Weave 1.3. Following a suggestion from IRC chat, setting services.sync.log.logger.engine.bookmarks to Trace revealed that the unresponsive time is spent going through the bookmarks (numerous lines of the type 2010-07-02 20:43:35 Engine.Bookmarks TRACE Mapped: Unsorted Bookmarks,bhttp:// (...) and similarly "Finding mapping...", "Mapped dupe...", "Outgoing..." when a change is detected. Unfortunately it appears this activity is not carried out unobtrusively in the background. Reproducible: Always Steps to Reproduce: 1. Ensure there is at least one change to the bookmarks 2. Sync Actual Results: Firefox temporarily but completely unresponsive Expected Results: Bookmarks sync carried out unobtrusively in the background

So it's probably because when it tries to detect dupes, it needs to create an in-memory mapping of your over 6000 bookmarks. Ideally we would use some built-in api to detect these dupes to avoid creating the mapping when processing incoming data.

This has been one of the single most annoying behaviors of Weave/Sync since the beginning, and it still occurs to some degree as of Sync 1.5.1. Firefox becomes completely unusable (to the point that Windows briefly states the application is not responding) during the initial part of the sync. It has gotten somewhat better over the past year, but is still prevalent and so annoying that I would almost rather uninstall it than gain the valuable bookmark sync features it provides.

This is most likely due to the fact that Sync is using synchronous I/O on the main thread to talk to the bookmark DB. Bug 626279 is about removing that.

We're using an increasing amount of asynchronous calls, and fixing the rest as core APIs become available. Since we never identified a root cause for this specific instance, resolving as INCOMPLETE, but it's likely fixed or significantly better.