D. Richard Hipp wrote:
On Nov 19, 2007, at 12:36 PM, James Dennett wrote:
-----Original Message-----
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Monday, November 19, 2007 7:36 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Memory Usage
Not only applicable to real time systems. If you want a program to
run
with stability over a long time the first step it to eliminate frees
and
if malloc is used confine it to the intialization.
I have to challenge this, not because it's entirely wrong (it's not),
but because it's an over-simplification.
I've worked with a lot of software that runs for years, and uses dynamic
allocation without problems. One of the keys to writing stable/robust
software is avoiding complexity, and *appropriate* use of dynamic
allocation can help with that in some situations.
There is, of course, a vast range of environments in which software must
run for years at a time, and the appropriate implementation techniques
vary. A pacemaker doesn't have the same constraints as a telephone
switch, or a satellite, or a set-top box or mobile phone, and even
within each of those categories there are wide ranges.
It's certainly nice that SQLite offers the flexibility to manage its own
fixed-size memory pool, but this certainly is not the only way to
produce stable, robust, long-running software.
Our studies to date indicate that SQLite neither leaks nor fragments
memory. Preventing leaks is relatively easy. Preventing memory
fragmentation less so. Yet we are not seeing memory fragmentation
as a problem for the workloads we have tested.
Nevertheless, we cannot *prove* that SQLite, in its current form,
will never fragment memory. However, we are working toward a
future release where such a proof will be possible, at least for
certain well-defined operating parameters. We just are not quite
there yet.
To be highly reliable and portable we tend to use brute force and
ignorance and maintain free lists of memory. It works reliably and
programs run for years but it is tedious to implement. It will
eventually reach a high water point which represents the worst case
memory allocation.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
