Closed
Bug 385804
Opened 17 years ago
Closed 6 years ago
perf test for mozStorage
Categories
(Core :: SQLite and Embedded Database Bindings, defect, P5)
Core
SQLite and Embedded Database Bindings
Tracking
()
RESOLVED
INACTIVE
mozilla1.9beta2
People
(Reporter: moco, Unassigned)
References
()
Details
Attachments
(1 file)
2.27 KB,
patch
|
Details | Diff | Splinter Review |
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
Comment 1•17 years ago
|
||
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.
Comment 2•17 years ago
|
||
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?
Comment 3•17 years ago
|
||
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.
Comment 4•17 years ago
|
||
(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.
Updated•17 years ago
|
Assignee: nobody → comrade693+bmo
Version: unspecified → Trunk
Updated•17 years ago
|
Target Milestone: --- → mozilla1.9 M9
Updated•17 years ago
|
Target Milestone: mozilla1.9 M9 → mozilla1.9 M10
Comment 5•17 years ago
|
||
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?
Comment 6•17 years ago
|
||
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-
Updated•16 years ago
|
Assignee: sdwilsh → nobody
Status: NEW → ASSIGNED
Updated•16 years ago
|
Status: ASSIGNED → NEW
Updated•8 years ago
|
Priority: -- → P5
Comment 7•6 years ago
|
||
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: 6 years ago
Resolution: --- → INACTIVE
Updated•17 days ago
|
Product: Toolkit → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•