SQLite has surprised me with its quick performance, not the other way around. In fact, I've implemented all kinds of lookup queries that I knew could be optimized by caching results so I didn't have to keep repeating the SQL query, but the performance was so good even repeating the queries that I never bothered with the caching.
I'm sure there are queries that SQLite doesn't run as fast as database product X, and I'm sure it goes the other way too. It's a balancing act, and as the primary developer, you have to choose for us what's important to optimize and what isn't. So far, I'm very happy with the choices and trade-offs that have been made in SQLite. :-) Jim On 5/30/09, Simon Slavin <slav...@hearsay.demon.co.uk> wrote: > I'm interested in how sqlite works differently to the SQL systems > which keep a daemon running as a background task. One of the > advantages of having a daemon which persists between runs of an > application is that the daemon can keep its own list of ORDERs, and > JOINs which are asked for frequently, and decide to maintain them even > when no SQL-using application is running. This can give the > impression that something is being done very quickly, when in fact the > majority of the time was taken during a previous run of the > application. It can be particularly hard to figure out what a > performance test means under these circumstances. > > But the problem is that I like the way sqlite works. I like the tiny > library, I like the way that the SQL library is entirely inside my > application, and any CPU load is mine. I like knowing that when my > app quits, nothing is going on. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Software first. Software lasts! _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
