User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1) Gecko/20090615 Firefox/3.5 Build Identifier: 1.1 When Weave reports in the status bar that it is synchronising my Browsing History, one CPU core will stick at 100% until it has completed this task. This often takes 2-3 minutes due to the very large amount of Browsing History which my Weave instance has to handle. Reproducible: Always Steps to Reproduce: 1. Execute a very large amount of browsing on one Weave-enabled browser. 2. Start a sync on a different computer to bring the history to it Actual Results: One CPU core can be observed stuck to 100% while "Weave is syncing Browsing History" is present in the status bar. This will often will cause "Window not responding" errors from Windows 7. Expected Results: Weave would be expected to apply the synchronised browsing history at a reasonable rate so as to not interrupt the browsing experience. An attachment will be created containing the verbose log of an example of one of these problem synchronisations.

Looking at the logs, it seems like it's hanging/busy for 20 seconds at a time each time it fetches a group of 150 history items. For each item, it needs to reconcile and potentially create the item if it doesn't exist. Some reason I remember posting stats of putting dummy logic for _isEqual and reconcile and how much it sped up things, but I can't find it right now... But basically, it seems like isEqual does 1 query and reconcile can do 2, and there's a base overhead of initiating a sqlite query even during a transaction, so these overhead costs add up.

http://hg.mozilla.org/labs/weave/rev/7cff747c3fa7 Sync asyncExecute to avoid forcing synchronous waits on disk but keep existing calling conventions (no callbacks) for callers by using Sync.

http://hg.mozilla.org/labs/weave/rev/759a7065ae20 Bustage fix from sync-asyncExecute: don't throw as the old code would catch and implicit return undefined.