Small (un-representative) benchmark on sqlite with blobs

[Andreas Pakulat]

On 25.06.07 15:59:16, Jens Dagerbo wrote:
> On 6/25/07, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 25.06.07 13:20:55, Roberto Raggi wrote:
> > > Il giorno 25/giu/07, alle ore 12:43, Andreas Pakulat ha scritto:
> > > > On 25.06.07 10:49:37, Roberto Raggi wrote:
> > > >
> > > > Nobody said we're going to store the data in a relational schema.
> > > > David
> > > > mentioned something like 2 Map-like tables. So the SQL-statements are
> > > > surely no problem. The real data will be stored as Blob, which is the
> > > > whole reason I did this experiment.
> > >
> > > interesting.. so why SQL? you can pretty much use everything else for
> > > that.
> >
> > As I already said: David had a couple of problems with the BerkleyDB in
> > KDevelop3. I don't care wether we use SQL or some binary database,
> > except that for SQL we already have pretty much everything in place
> > (high-level API, sqlite plugin that is almost always built for QT,
> >
> 
> But.. in KDev3 the database was actually used for queries.. if you are
> saying it should all go into a blob, why not simply use a file on
> disk? What does the the database give you at all in this case?

Nothing, except that we have all in one file.

> And while on topic.. all data in one blob?? You're only interested in
> persistence here? It seems to suggest that you will have all of the
> data (duchain, whatever) in memory during normal operation, but surely
> that will use up way too much memory? KDev3 kept (and persisted) only
> the project PCS in memory, and used bdb for lookups against external
> libraries. This to keep the memory usage down. (And with large
> projects, this was a bit too heavy too.)

I'll leave that for David, because I don't know how large AST+DUChain
stuff might get.

Andreas

-- 
You will be married within a year, and divorced within two.