My reading of the SQLite blurb is that code written for earlier versions will run on the latest version.
http://search.cpan.org/src/ISHIGAKI/DBD-SQLite-1.43_02/Changes - that's the perl module's changelog. It lists at least three warnings about changes which might break old code.
My thinking was that if you could update SQLite in 7.9 and tell us in the 7.9 thread then the guinea pigs amongst us would try it out and report back.
Unfortunately I don't have any data about what perl versions are being used on the various platforms. The 7.9 population is still rather small though...
Looking at the 7.8 data, most installations seem to be running on Windows. Good: one perl version, one architecture we support. Then things become more interesting. There are at least three major groups of Linux systems (i386, x86_64, ARM of some flavour). These could be (and sure will be) using different Perl versions. Plus OSX. Makes already quite a few build processes.
Maybe if we did Windows, recent Ubuntu 32/64-bit, ARM Linux as run on CSOS and Mac (because I want it :-)) we could get pretty good coverage already.
But maybe it is not that simple....
It's a lot of work.
As to the option to use extra ram, I and others (http://forums.slimdevices.com/showth...hlight=ramdisk) have boosted the speed of New Music and other browsing functions by installing RAMDisk on Windows for libraries over 100,000 tracks. My thinking was that if more of the database was in ram then it would perform better and avoid having to fiddle about with RAMDisk.
The huge difference between running the cache from ramdisk and letting the DB use more memory is that the DB sooner or later will write to your disk anyway. On a RAM disk you defer _all_ disk IO to whenever you do a backup of the RAM disk. Until then it's all in RAM and most likely will always be faster.
As I have just discovered after converting an old Win XP box to VortexBox 2.3, SQLite performance on Windows (XP and Win 7) for 100,000 track databases is abysmal compared that on Linux.
If somebody had the knowledge and time to figure out why Windows is performing so poorly compared to Linux, that might help as well...
-- Michael _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
