3 ms·
> I don't like databases, and the reason I don't like them is that they seem to cause terrible performance problems in web browsers. Disk I/O is slow, so any k
by aartur 13y ago
> I don't like databases, and the reason I don't like them is that they seem to cause terrible performance problems in web browsers.
Disk I/O is slow, so any kind of disk storage will be slow. I'm sure storing web browser's data in some kind of ad-hoc files would be much slower than SQLite. And the fsync() issues are orthogonal to using flat files/DB.
- millstone 13y agoI believe ad-hoc files would handily have outperformed SQLite. One reason is that SQLite does not use optimal disk access patterns. I know this because I have watched it issue nothing but preads and pwrites for literally hours, on a database that was about 2 GB. This is obviously terribly pathological behavior, and it was in shipping products. (incrVacuumStep is the bane of my existence.) The second reason is that SQLite provides strong data integrity guarantees by default, at the cost of performance. This has proven to be a bad tradeoff for many applications, including Firefox. > And the fsync() issues are orthogonal to using flat files/DB They are not orthogonal, because SQLite calls fsync a lot by default, and it takes work to understand what you're doing that causes it, or even to disable it. See https://bugzilla.mozilla.org/show_bug.cgi?id=421482 https://bugzilla.mozilla.org/show_bug.cgi?id=421482 for some of the pain this caused. Notice some of the timing differences - one user reported that disabling SQLite async IO reduced his shutdown times from 1m40s to 5 seconds. This puts the lie to your "any kind of disk storage will be slow" claim: disk access patterns can have enormous impact, and empirically, it's easy to use SQLite in a way that destroys your performance.