Sorry for the delay in posting this. We don’t yet have a frontend for tracking SQL performance in Firefox. Had to wait on Xavier to become available to do the manual reports for me.
product product_version channel sql doc_count sum_count quantiles(min,0.25,0.5,0.75,0.95,max)
Firefox 12.0a2 aurora INSERT INTO webappsstore2_temp (scope, key, value, secure, owner) SELECT scope, key, value, secure, owner FROM webappsstore2 WHERE scope = :scope AND NOT EXISTS ( SELECT scope, key FROM webappsstore2_temp WHERE scope = webappsstore2.scope AND key = webappsstore2.key ) 2970 6676 (100.0,133.0,199.0,365.0,1731.0,244503.0)
Last column shows the time it takes to prepopulate DOM local storage for a webpage in milliseconds. It means in the worst case it took 4minutes before the filesystem decided to give us what we asked for. For 95% of the users reporting it took < 1.7seconds to preload local storage, for 75% < 0.36seconds, etc.
Generally IO is quite fast, but these terrible corner cases means that responsible software developers should always do async IO in interactive applications. Note that this has little to do with how we are accessing data from disk and everything to do with disk IO latency being non-deterministic.
What about other SQL queries?
Feel free to explore the other slow SQL queries in the product, most of them already have Snappy:P1 bugs filed. The plan for snappy is to systematically annihilate the worst performing IO in the browser ASAP.
This data shows why doing SQL IO in applications is both a curse and a blessing. On one hand, a general purpose relational database is always going to be slower than an application-specific storage mechanism. On the other hand, it is a very nice abstraction that makes analysis like this trivial.