For some reason, removing history entries from the Library view doesn't scale linearly. Removing 400 entries is quite fast, removing 1000 entries takes lots of time and makes the "unresponsive script" dialog appear about twice. Bug 681420 made us remove history entries in chunks but this doesn't seem to help much. Removing 1000 entries (with a chunk size of 300) looks as follows: 1st slice 25433ms 2nd slice 5315ms 3rd slice 3076ms 4th slice 540ms The profile shows that we're spending most of the time not removing history entries but re-painting and managing the tree view: http://people.mozilla.org/~bgirard/cleopatra/#report=f129e876100813a449ba79852051c360d11e35f8

The profile shows that these function are called a lot: * goUpdatePlacesCommands() * goUpdateDownloadCommands() * goUpdateGlobalEditMenuItems() Every time onxblselect is fired on the tree all commands are updated. That is probably done every time the tree is updated.

Making these functions no-ops improved removing ~1000 entries: 1st slice 3093ms 2nd slice 2759ms 3rd slice 2129ms 4th slice 819ms No unresponsive script dialogs popped up. I think there's still some room for improvement if we for example don't update the tree at all until all items have been removed.

Thank you for filing this, I recently noticed things had regressed since bug 681420 but hadn't remembered to file a bug about it, oops!

this is a recent regression instead