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