I'd like to chime in that we have somewhat similar requirements: Our app is heavily threaded and we had sqlite's memory allocations show up as bottlenecks at times. This happened when the 'new' allocators that allow for high-water marks, etc. appeared first. Since we don't need any of the high-water alert features, we decided we'd revert back to a bare-bones memory allocator that would essentially just wrap around the malloc(), realloc() and free() system APIs. This improved performance quite a bit for heavy threading situations.
Is there any work being done trying to either minimize the synchronization needed or provide a memory allocator that doesn't do all the alerting, but also doesn't require to synchronize each single allocation? Our experience is that the OS allocators seem to do a much better job in heavily threaded situations without too much blocking... Thanks, </jum> Am 21.03.2008 um 22:23 schrieb Mark Spiegel: > The closest memory implementation would be the default one. The other > implementations that try to do their own pool management are > unacceptable as memory system wide to too valuable to allow SQLite to > allocate pool that it is not currently using. I am also > fundamentally > opposed to trying to outsmart the memory manager until someone can > demonstrate a need to do so. I have yet to see a successful effort to > do this in my environment. > > Back to the default implementation, the trouble is that there is too > much heavy synchronization and it prevents me from using available > high > performance memory management primitives and available debugging > support. Performance and space are critical factors. I'm working in > the NT system it would be unreasonable of me to expect that any of > your > implementations to be well suited to that environment. That's why I > found the SQLITE_OMIT_MEMORY_ALLOCATION exciting. I was fully > expecting > from the beginning that this would be an area that I would have to > implement just like the VFS and mutex support. The difference is that > now I have to make a few changes to the amalgamated source to do it > rather than just #define a value. No problem. > > Thanks for your help. > > [EMAIL PROTECTED] wrote: >> Mark Spiegel <[EMAIL PROTECTED]> wrote: >> >>> I'm looking to jump my code port forward from 3.5.1 to 3.5.7. >>> >>> Clearly I have some memory management work to do since >>> SQLITE_OMIT_MEMORY_ALLOCATION support has been dropped. None of the >>> existing allocation implementations look acceptable so I'll have >>> to roll >>> my own, >>> >> >> What do you need that none of mem[12345].c provide? >> >> >>> but that looks pretty straight forward. >>> >>> Two questions: >>> >>> 1) Has the VFS interface changed from 3.5.1 to 3.5.7? >>> >> >> No. >> >> >>> 2) Is the SQLITE_MUTEX_APPDEF #define still supported in the same >>> manner >>> from 3.5.1 to 3.5.7? (It appears that it is, but it never hurts >>> to ask.) >>> >> >> Yes. >> >> >> -- >> D. Richard Hipp <[EMAIL PROTECTED]> >> >> _______________________________________________ >> 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
