From: Calum Grant (calum_at_[hidden])
Date: 2005-09-29 15:18:28
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Andreas Pokorny
> On Wed, Sep 28, 2005 at 10:50:51PM +0100, Calum Grant
> <calum_at_[hidden]> wrote:
> > > [mailto:boost-bounces_at_[hidden]] On Behalf Of
> Andreas Pokorny
> > > On Tue, Sep 27, 2005 at 09:24:24PM +0100, Calum Grant
> > > <calum_at_[hidden]> wrote:
> > > > Is there any interest in providing relational
> containers in Boost?
> > > > Are there any features/improvements you can suggest for RML?
> > >
> > > You could compare the library with sqlite.
> > Completely different. Most database engines are controlled
> via text
> > strings, and require parsing and data transformation. This
> cuts all
> > that out using C++ templates, and is therefore way faster. It's a
> > container.
> Oh, sorry my request was not formulated clearly enough. I
> wanted to see how rml performs compared to sqlite in a
> benchmark. Sqlite is currently
> a nice and fast solution if you do not need a remote
> database. Rml could
> be an even better solution, if you do not require a text sql
> interface, provided that there are table types available in
> rml, which work without
> being fully loaded to memory.
> > > Furthermore you could implement a table that can be stored in
> > > a file, and used wihout reading all records into memory.
> > I think the memory-mapped file route would be the most
> profitable, it
> > would probably already work.
> Interesting, could you give a short overview, how it could
> already work.
You could use an allocator with RML (or indeed any STL container) that
stores the data in a memory-mapped file. This basically makes the data
I actually had a project a while back that did such a thing, and got
some good benchmarks comparing MySQL vs file-mapped containers:
and I'm sure boost::shmem::allocator is similar. Performance is very
good. We could devise a benchmark and I'll implement in RML +
Persist/Shmem, you implement in SQLlite and we'll see the difference.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk