Quoth Stephan Beal <sgb...@googlemail.com>, on 2013-06-23 03:07:02 +0200: > file db: > ==16021== total heap usage: 856 allocs, 856 frees, 222,957 bytes allocated > > vs :memory: > ==16043== total heap usage: 832 allocs, 832 frees, 203,430 bytes allocated > > (Most of those allocs were done by my code, not sqlite.) i'm just curious > how the second one could possibly allocate less than the first.
Here's a plausible explanation that I haven't thoroughly verified. For both cases, for such a small database, all the actual data is likely to wind up in the page cache. For an in-memory database, however, there's no need to manage an actual file descriptor, filename, filesystem-based locks, possibly certain header information... Especially, note that on Unix-y platforms, where POSIX fcntl locking is used, SQLite keeps internal global state matching up fds to inodes. This is so that if you open the same database multiple times, and a lock is ever taken on one connection, no other such connection can close its fd before the first lock is released. Otherwise, due to fcntl's broken design, the close would release the lock immediately, potentially resulting in database corruption. The difference is not particularly large, and is easily explainable by some combination of the above or similar. If you want something more exact, of course, feel free to run a source-level trace using your favorite allocation analysis software and report back. :-) ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
