Version 3.6.13 fixed some potential alignment issues that could occur on SPARC (and potentially other) architectures. I don't know how you or Apple are testing your app, but if you (or they) are using a device emulator for the testing, the emulator might not be testing alignment conditions the same.
HTH. -Shane On Tue, Apr 21, 2009 at 11:27 AM, D. Richard Hipp <d...@hwaci.com> wrote: > > On Apr 21, 2009, at 11:10 AM, Mark Spiegel wrote: > > > I'm a bit confused by the following: > > > > "The assign 100K or so to each database connection's lookaside memory > > allocator using sqlite3_db_config(SQLITE_DBCONFIG_LOOKASIDE, ...) > > immediately after it is opened." > > > > If memory is at a premium, why would you reserve a large amount of it > > for SQLite's "look aside allocator"? (It's really a zone allocator.) > > This SQLite mechanism ostensibly attempts to trade memory for > > speed. If > > memory is at a premium, in this case a fixed upper bound, that trade > > off > > doesn't seem to make sense. I would think in a case where memory is > > tight, zero bytes should be reserved. > > > > This is a reasonable observation. > > On the other hand, the lookaside memory allocator (which is just a > zone allocator, as you observe) makes a big performance difference. > And if you only have a single database connection, it doesn't really > matter if the memory goes into lookaside or is in the global heap. If > you have multiple database connections, you might get increased memory > efficiency by sharing between those two connections - which cannot > happen with lookaside. > > The page cache is going to be the biggest user of memory. The page > cache memory will probably be measured in megabytes. Memory used by > lookaside is measured in kilobytes. A few dozen KB of additional > memory assigned to lookaside won't make that much difference in your > overall memory usage, but it will make a difference in performance. > So it seems to me to be worth the tradeoff, even if memory is tight. > > The reason I suggested using sqltie3_db_config() to assign a static > buffer for lookaside is so that the lookaside subsystem will not go to > the heap to get its (default) 50K allocation. The MEMSYS5 memory > allocator is a first-fit power-of-two memory allocator specifically > designed to avoid memory fragmentation and hence allow applications to > be designed that are guaranteed to never fail a memory allocation. > But doing large heap allocations (more than 2K or 4K) tends to defeat > the anti-fragmentation properties of MEMSYS5. Hence, we desire to > avoid the 50K heap allocation for the initial lookaside buffer. One > could, as you observe, achieve the same result by turning lookaside > off all together, but then you take a performance hit. > > D. Richard Hipp > d...@hwaci.com > > > > _______________________________________________ > 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
