On Mon, Sep 19, 2016 at 4:56 PM, James K. Lowden <jklow...@schemamania.org>
> On Wed, 14 Sep 2016 16:27:37 +0530
> But I agree with Teg: SQLite is providing you with transactions you
> don't need, and puts an interpreted language exactly where you don't
> want it: in a performance-critical spot. The C++ standard library has
> all the bits you need, and is almost as convenient to use.
> You have only one table, and probably just a few simple queries.
> std::set gives you lower_bound and upper_bound. Hand those two
> iterators to std::accumulate, and you have GROUP BY. Call that for 5
> prices. Not very much code, and I bet 100x faster than SQL. If more
> than one thread is updating the table, obviously protect your set with
> a mutex.
In addition to James' excellent answer, I'd add that using C++/STL
doesn't preclude you from having SQL on top of them, thanks to SQLite's
For example, FWIW, I extensively use Boost's Multi-Index containers,
which are like statically indexed tables (you decide what indexes you want,
at compile time), and layer read-only virtual tables on top, properly
the static indexes to SQLite's query planner (via xBestIndex). That way you
can use C++ when you want, but can still benefit for all the flexibility of
which happens to read even faster than SQLite's in-memory DBs. --DD
sqlite-users mailing list