Roger and John both, of course have good points - John Stanton has correctly pointed out that there is a programming model where an application effectively does the cacheing itself by precompiling statements at startup. In this situation, the proposed cacheing feature represents double work, and double memory (or worse).
My proposal of a statement cache, which Rodger Binns supports, is based on the idea that an application does not store prepared statements. In this case, the performance benefits are clear. I have no doubt that both approaches are in common use, and neither is, IMHO, 'wrong'. It seems to me that a run time control (a pragma?) to enable/disable the feature would accommodate both program models. In addition, a compile-time feature macro to prevent the bloatware problems for embedded applications is in order. I believe the pragma should enable cacheing, so the default is with cacheing disabled. This makes the feature transparent to *all* existing programs. The compile-time Macro should default to include the cacheing feature. This makes the feature available normally. Those who are memory conscious will probably be rebuilding the library anyway, since it is likely that other compile-time changes would already be necessary to reduce the size of sqlite. *** Doug Fajardo -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Stanton Sent: Monday, November 10, 2008 8:15 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Distinguishing between sqlite3_stmts You make a argument for Bloatware. It is not oersuasive. JS Roger Binns wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Stanton wrote: > >>Perhaps this featrure could be reserved for "Sqlheavy", a replacement >>for Oracle. > > > Or a #if OMIT_STATEMENT_CACHE like all sorts of other functionality that > can be omitted. > > >>We have actually implemented the cacheing of prepared statements, and >>add it in the form of a local library which extends the Sqlite API. > > > If almost everyone is doing a statement cache then there is a stronger > argument for it being part of the core library. > > >>Cacheing compiled SQL is only helpful in certain types of application. > > > I'd argue that it is helpful in most applications that use bindings and > don't implement their own statement caching. > > >>In a typical emdedded application where all SQL is compiled as the >>application intializes and subsequent usage involves the binding of >>variables cacheing would be detrimental to performance and footprint. > > > Caching would increase memory for one off queries since unused > statements would be in the cache. In your scenario there would actually > be no difference since the cache would be empty. A SQLite hash table > with no entries is approximately 28 bytes. > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkkV6qIACgkQmOOfHg372QTsOgCggRTY1TSkxHLznv95G64N+PjH > p34AoMHMjgGsxZTgufEVUz7hP6uM8/14 > =0HbU > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
