On Mon, Oct 26, 2009 at 2:48 PM, D. Richard Hipp <d...@hwaci.com> wrote:
> On Oct 26, 2009, at 5:00 PM, Peter Kasting wrote: > > as > > far as > > I can tell the current code shouldn't cause any performance hit by > > enabling > > this flag. There's no additional monitoring/tracking it causes; it > > just > > exposes a few functions to free memory. Has the memory management > > implementation changed since the previous thread, or is this feature > > now > > broken? > > We run the "fulltest" test suite on a build of SQLite that include > SQLITE_ENABLE_MEMORY_MANAGEMENT prior to every release. The > sqlite3_release_memory() interface works as documented, as far as we > know. Are you seeing something that would suggest otherwise? > I think you're misunderstanding the thrust of my question. I'm saying that based on a glance at the current code, it doesn't look like past comments about the perf impact of this flag would be accurate anymore. I want to know if my supposition is true. Presumably, if it is true, it's either because memory management has been rearchitected since that old thread, or else because the feature has become broken. I'm not saying I think it's broken, simply that that would be one possible explanation for the discrepancy between what it looks like the code does and what it sounds like it used to do. The other question in my email, regarding the reason for the #if 0 inside sqlite3_release_memory(), is eprhaps more interesting to me. PK PK _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
