Phiho,

I haven't worked with SQLite so I really can't say one way or another.
As for which has the smaller footprint, I don't know that either.  But,
here are the file sizes that I know of for BerkeleyDB:

Win32 DLL: 585,728 bytes
Linux .so: 598,350 bytes
Linux .a : 798,490 bytes

SQLite appears to be an SQL engine.  BerkeleyDB is not, so you're really
comparing apples and oranges anyway.  I really don't have a need for SQL
(or a relational model in general) and my guess is that supporting SQL
would make the API more complex than BerkeleyDB (aside from cursors,
transactions, locking and maintenance issues, the BerekelyDB API boils
down to just a "get" and a "put" operation...which is all you need if
you're storing Squeak objects and don't need SQL for some other system
to access your objects).

On the website the SQLite API appears to consist mainly of just a three
functions, open, close, and exec.  But of course, exec is the SQL
execution function, and you have to consider that SQL itself is a rather
large API.

One of the things that I like about BerkeleyDB is that if your needs are
simple, there are only a few API functions you need to worry about, but
if your needs grow, BDB appears to be quite capable in the areas of
transaction control, scalability, locking, and fault tolerance.

On the other hand, if you need SQL, then BerkeleyDB shouldn't even be a
consideration.  A better comparison might be SQLite vs MySQL (which has
the ability to use BerkeleyDB for its table storage).  There might be
some other lightweight SQL solution built on top of BerkeleyDB that
might be more comparable to SQLite, but I haven't seen any myself.

What I'd really like to find is something that is comparable to
BerkeleyDB but with a more open license.  I haven't found anything that
fits that description.  One interesting possibility might be to take
just the B-tree driver out of SQLite and use it (although, I don't see
any reference on the SQLite website to its license).

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of PhiHo Hoang
> Sent: Sunday, October 27, 2002 3:31 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Persistent VM (was Re: [ANN] New Version of VI4 
> (block closures))
> 
> 
> Hi Stephen,
> 
>     You used Berkeley DB for your Persistent VM.
> 
>     What do you think of SQLite, which has a smaller footprint ?
> 
>     Cheers,
> 
>     PhiHo.
> 
> ----- Original Message ----- 
> From: "Stephen Pair" <spair at advantive.com>
> To: <squeak-dev at lists.squeakfoundation.org>
> Sent: Wednesday, October 23, 2002 8:35 AM
> Subject: RE: [ANN] New Version of VI4 (block closures)
> 
> 
> > Hi Anthony,
> > 
> > Will you be at OOPSLA?  VI4 sounds great...have you compared the 
> > performance of generating the interpreter of the two VMs?  
> Here's the
> > code:
> > 
> > Smalltalk garbageCollect.
> > [((CCodeGenerator new initialize
> > addClass: Interpreter;
> > prepareMethods;
> > doInlining: true)
> > cCodeForMethod: #interpret)] timeToRun
> > 
> > In working on the "Chango" persistence VM, I've found that 
> > #tinyBenchmarks doesn't really give an accurate picture of real 
> > performance.
> > 
> > Anyway...I'm planning to demo my persistence VM at OOPSLA and would 
> > like to re-implement it on top of VI4 (I may gain back some of the 
> > performance I lost ;) ).  It would be nice to sit down with 
> you to get 
> > an idea how much work that would entail.
> > 
> > Cheers,
> > Stephen
> > 
> > > -----Original Message-----
> > > From: squeak-dev-admin at lists.squeakfoundation.org
> > > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> > > Behalf Of Anthony Hannan
> > > Sent: Wednesday, October 23, 2002 1:42 AM
> > > To: squeak-dev at lists.squeakfoundation.org
> > > Subject: [ANN] New Version of VI4 (block closures)
> > > 
> > > 
> > > Hello Squeakers,
> > > 
> > > I'm pleased to announce that I'm finally finished with the
> > > latest version of VI4.  You can get it from its usual place 
> > > at http://minnow.cc.gatech.edu/squeak/VI4.  It has been 
> > > rewritten and cleaned up and should be very stable.  Once 
> > > other image format changes are incorporated (if any) and once 
> > > it is approved for a future Jitter, it should be ready 
> for prime time.
> > > 
> > > The Interpreter still operates directly on the process stack
> > > object, but hooks have been provided so the process stack can 
> > > be internalized by the VM if desired.  See the aboutVI4 
> > > method comment for more details.
> > > 
> > > 0 tinyBenchmarks reports a 30% increase in bytecode speed and
> > > a 75% increase in send speed.
> > > 
> > > Enjoy!
> > > Anthony
> > > 
> > > 
> > 
> > 
> > 
> 
> 
>