Well if you're doing an in-memory database - why not skip the database all together and just build up data structures in memory?
For WebSurge in .NET I basically created large lists in memory and query them with LINQ which is very fast since it's all in memory - even when running against several gigabytes of data search perf is super fast. I suspect the same will be true in other environments assuming there's an efficient query interface like LINQ in .NET.
I just think an in-memory database doesn't much of anything unless you're loading up huge amounts of data that require the in memory b-tree indexing.
+++ Rick ---
>Hi Rick,
>
>Thanks for dropping in,
>
>>SqLite is very dependent on proper configuration to get good performance out of it. Default config is pretty slow... but with turning off the transaction log (journal) and in >memory usage it can do OK.
>
>Yep, that's what I read up to now. You definitely need to turn the journaling off.
>
>>It works great as a single user Db, but make sure you don't need multi-user access in the future because it's terrible for that - basically locking the entire db for any >updates which is very inefficient.
>
>The intended usage, as an application session-wise-only data storage - very much in the way vfp-cursors are sometimes used within some vfp apps - requires zero multi-user access. Except when debugging where access may be done as a way to investigate and debug, the access to the db is intended from a single user and two threads, a GUI one and the (long-)process-one.
>
>I am always impressed by rushmore speed on indexed cursors. I will run a couple of tests on the relative perf of rushmore sql queries and and "in-memory" sqlite from python on this thread as soon as I'll have my feet wet on the project.
>
>Since python code does not run faster than good ol' vfp, I hope that I'll be able to replace the current set of rushmore-based data crunching with "in-memory" sqlite , properly tuned as you hinted.
>
>There are of course possibly LOTS of alternatives to speed things up in python. I would like to be able to shunt cython-based (aka python FLLs) optimizations, numpy, numba and other speed-up solutions when starting the rewrite at least for the initial version of the app.
>
>Daniel