perf test for mozStorage

RESOLVED INACTIVE

Status

()

Toolkit
Storage
P5
normal
RESOLVED INACTIVE
11 years ago
2 months ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Unassigned)

Tracking

Trunk
mozilla1.9beta2
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

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

11 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

11 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

11 years ago
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.

Updated

11 years ago
Assignee: nobody → comrade693+bmo
Version: unspecified → Trunk

Updated

11 years ago
Target Milestone: --- → mozilla1.9 M9

Updated

11 years ago
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?

Comment 6

11 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

10 years ago
Assignee: sdwilsh → nobody
Status: NEW → ASSIGNED

Updated

10 years ago
Status: ASSIGNED → NEW

Updated

2 years ago
Priority: -- → P5

Comment 7

2 months 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
Last Resolved: 2 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.