Closed Bug 385804 Opened 12 years ago Closed Last year

perf test for mozStorage

Categories

(Toolkit :: Storage, defect, P5)

defect

Tracking

()

RESOLVED INACTIVE
mozilla1.9beta2

People

(Reporter: moco, Unassigned)

References

()

Details

Attachments

(1 file)

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?
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
Target Milestone: --- → mozilla1.9 M9
Target Milestone: mozilla1.9 M9 → mozilla1.9 M10
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.
Flags: blocking1.9?
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-
Assignee: sdwilsh → nobody
Status: NEW → ASSIGNED
Status: ASSIGNED → NEW
Priority: -- → P5
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
Closed: Last year
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.