Persistent VM (was Re: [ANN] New Version of VI4 (block closures))

PhiHo Hoang squeak-dev at lists.squeakfoundation.org
Mon Oct 28 15:54:38 UTC 2002


Stephen,

> 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).

    First off, I think I read somewhere that SQLite is not even copyrighted.

    On the homepage  http://www.sqlite.org/ ,
    in the Features section (last bulleted item) :

            "Sources are in the public domain. Use for any purpose."

    For Windows, the 'sqlite.dll' 2.7.2 is 187KB.
    For Linux, 'sqlite.so' 2.7.2 is 222KB.

    The B-tree driver is pretty small. I have not tried to build just the
B-tree driver but btree.c is just 99KB.

<QUOTE>
An SQLite database is maintained on disk using a B-tree implementation found
in the btree.c source file. A separate B-tree is used for each table and
index in the database. All B-trees are stored in the same disk file. Each
page of a B-tree is 1024 bytes in size. The key and data for an entry are
stored together in an area called "payload". Up to 236 bytes of payload can
be stored on the same page as the B-tree entry. Any additional payload is
stored in a chain of overflow pages.

The interface to the B-tree subsystem is defined by the header file btree.h.
</QUOTE>

    I don't need the SQL part either. Just the B-tree driver is good enough.
    (BerkeleyDB is more sophisticated though).

    Actually, the SQL part is a burden, query through SQL is very slow.

    I like to access the B-tree direcly (not even through a primitive ;-)

    I think Smalltalkers would like SQLite because it is typeless (SQL) and
has a VM ;-)


    Maybe you want to compare just the B-tree part from BerkeleyDB and
SQLite.

    Best wishes for your Persistence VM.

    Cheers,

    PhiHo.


----- Original Message -----
From: "Stephen Pair" <spair at acm.org>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, October 28, 2002 9:45 AM
Subject: RE: Persistent VM (was Re: [ANN] New Version of VI4 (block
closures))


> 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
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>




More information about the Squeak-dev mailing list