Storage has many consumers we care about perf, like the awesomebar, it's possible pgo on sqlite (provided we pgo C code) is enough, but no idea, off-hand I don't like much the idea to avoid optimizing something we always cared to keep performant.
It's not like the compiler won't do optimization; it just won't be informed by runtime info. Especially since well-behaved storage use should be I/O bound and on a background thread, storage/sqlite seems like a great place to take the hit in the name of faster JS/layout/XPConnect.
Also, as I said elsewhere, the PGO profiling phase doesn't actually examine the awesomebar and the like, so I wouldn't be surprised if PGO doesn't actually optimize the code related to that much.
Assignee: nobody → ehsan
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
You need to log in before you can comment on or make changes to this bug.