One other note, just about all real-time systems limit the dynamic
allocation of memory because you lose the deterministic behavior,
typically all memory is allocated when the task starts, memory is
usually managed internally in standard sized chunks.
Also for long running tasks (months/years) you would suffer
fragmentation and for limited memory systems a malloc/new may fail
weeks after the task starts and that would not be pretty. Also it is
very hard or even impossible to completely test, it is best to design
the problem out.
Thus it is nice to have the ability to turnoff sqlite's ability to malloc
D. Richard Hipp wrote:
On Nov 18, 2007, at 8:12 AM, Russell Leighton wrote:
On Nov 17, 2007, at 4:56 PM, [EMAIL PROTECTED] wrote:
If you compile with -DSQLITE_MEMORY_SIZE=nnnn then SQLite
will *never* call malloc(). Instead, it uses a static
array that is nnnn bytes in size for all of its memory
needs. You can get by with as little as 100K or so of
memory, though the more memory you provide, the faster
it will run. 5MB is a good value.
Does using this setting (and eliminating malloc/free overhead) result
in a significant performance increase?
That depends on how good of a malloc you have on your system.
On Linux systems that typically use Doug Lea's malloc, there is
no measurable performance difference. But I have had some
people running embedded systems tell me that using the
malloc-free SQLite results in a significant speed boost. Your
mileage may vary.
D. Richard Hipp
[EMAIL PROTECTED]
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
