perf test for mozStorage from http://wiki.mozilla.org/WeeklyUpdates/2007-06-25#Firefox_3 "mozStorage (sdwilsh) Updated sqlite to 3.3.17, lots of fixes and perf wins" Perhaps we should come up with some perf tests (for us to run before checkins) to make sure that upgrades to sqlite or changes to mozStorage don't regression performace. I'd also be curious to see what the gains were from upgrading to 3.3.17
i'll post some comparative numbers here from my cookie testing in the next couple days (specifically re async) if someone can help with xpcshellifying those tests to run with a profile, we could run them as unit tests.
see https://bugzilla.mozilla.org/show_bug.cgi?id=230933#c29 for some background numbers on storage perf before the sqlite upgrade. after doing tests on pre- and post-upgrade builds, for INSERTing 1000 cookies into the db (patch used for testing to follow) either using or not using a transaction for the entire operation, all times in microseconds, averaged over 8 runs: old sqlite no transaction, synchronous (default) writes: 1074982 no transaction, synchronous=OFF: 108011 transaction: 6877 new sqlite no transaction, synchronous (default) writes: 692053 (36% faster) no transaction, synchronous=OFF: 108755 (~ no change) transaction: 6514 (5% faster) so, the new code is faster for synchronous writing with or without transactions, but for async writing it's the same. (note that when using transactions, sync makes no difference, since the db is written to disk only once). which is curious - wasn't it claimed that the new code was 35% faster in async mode?
Created attachment 269825 [details] [diff] [review] patch used for tests in comment 2 to use this, start out with a clean profile, start firefox once to generate a cookies.sqlite file. copy it to cookies.sqlite.backup. each time you start firefox the perf test will run; afterward, copy the backup file over cookies.sqlite to reset the database. the two commented lines are used for the sync and transaction variations of the test.
(In reply to comment #2) > which is curious - wasn't it claimed that the new code was 35% faster in async > mode? Nope - we implement async ourselves. They synchronous improvements make sense though.
Assignee: nobody → comrade693+bmo
Version: unspecified → Trunk
I'm only going to devote time to this if it's marked blocking or told to do so by a driver. If someone decides this should be blocking+, please set the target milestone and priority appropriately so I can plan my other bugs around around it.
This would be nice to have - and we may require this if we want to change sqlite but we are not going to block on this
Flags: blocking1.9? → blocking1.9-
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.