On 18 Jul 2014, at 11:50pm, Richard Hipp <[email protected]> wrote: > Hard to say. There are a lot of dependencies.
A lot. There's no point in us publishing figures of any kind since they'll be useless for you. All someone could do is look at comparisons between the two things on one hardware setup. > In a test of reading BLOBs out of an SQLite database (seen at > http://www.sqlite.org/intern-v-extern-blob.html) we find that SQLite can be > up to 2.5x faster or 4x slower than direct file I/O depending on the BLOB > size and the page size of the database file. I'm guessing -- and it's only a guess -- that much of the delay in reading individual files is caused by two things: (a) Opening separate files for each BLOB involves opening files, which is slow because the OS has to check many things for each file opened, including whether this user should be allowed to read that file. (b) With all the BLOBs in one file there's a higher chance of cache hits as you move from one BLOB to another. >> Secondly, is this even a valid test? Would someone want to store non >> indexed data in SQLite table? I've done it when dividing a row into columns was extremely useful to my application. I had a choice of putting the logic to identify fields from a text file into an already-complicated piece of code or storing is into a SQL database and being able to specify the field names I wanted. Having said that, that application needed SQLite for other purposes so it had the SQLite source code in it already. I might not have bothered otherwise. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
