Kay, I'm puzzled by your remark about sqlite below. SQLite is an in-memory database with a very small footprint and I doubt you will find a faster SQL implementation. That's not to say it's perfect for all uses, partuclarly in a multi-user enviornment, but the fact that it's used in abundance on just about any mobile device you care to name attests to its efficiency in relatively low powered environments.
I'm not sure what you mean by "industrial strength" but I know of people who have millions of rows in a table and have no problems maintaining or retrieveing their data in a timely manner. SQLite has settings for controlling memory use, cache sizes, and many other variables. They are all accessed via its PRAGMA statements. I can't know, of course, if Apple has tweaked those settings for best performance but it's unusual to have to change them at all. I'm under the impression that OS X has used sqlite dbs behind the scenes for years so it seems unlikley that SQLite can be blamed for the performance issues that some of us are seeing in Lion. Pete lcSQL Software <http://www.lcsql.com> On Tue, May 29, 2012 at 8:37 PM, Kay C Lan <lan.kc.macm...@gmail.com> wrote: > My personal opinion on why Lion can be sluggish and resource hungry is that > so much of it now has SQLite as it's backend which I know is slower than > other DBs out there. I also THINK (no actual hard evidence) that in some > cases people are requiring industrial strength performance out of it and it > just isn't set up for that. Other DBs have all sorts of settings for > memory, cache, VM etc, to maximise performance depending on the particular > type/size of data you are dealing with. I'm not sure if any such tweaks > occur to the OS X SQLite DBs. > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode