Aha. The display of the number of songs on the start page explains the read accesses.
I dug into the subject a little further and tried DBD::RAM (which is outdated and does not work any more) and DBD::AnyData instead of SQLite. To my dismay, I found that AnyData speaks a slightly different SQL dialect, so that the dbcreate.sql would have to undergo heavy changes in order to make that work. However, I found that SQLite is one mighty tool that has not yet been used to its full potential by Slimserver. As you can see here: http://www.sqlite.org/pragma.html, there is room for improvement. When you insert the following code: $dbh->do("PRAGMA temp_store = MEMORY"); $dbh->do("PRAGMA cache_size = 60000"); into .../Slim/DataStores/DBI/DataModel.pm at line 184 (just before the "$dbh->commit()"), you get rid of the temp-file creation and you can cache all (or at least most) of the database in memory. This comes at a cost of ~90 MBytes maximum increased memory consumption using my example of 60000 for cache_size (this is according to the SQLite specs). Matter-of-fact, my memory consumption went from 45M to 72M, which is neglegible. One could use other PRAGMAs, like "synchronous = OFF", but I have not made it work, maybe because Slimserver uses AutoCommit=0. Also, you can use "default_cache_size = XXX", this should make the cache size persistent in the database, so that further Slimserver updates do not neccessarily need the second improvement any more if you keep the database. For me, these modifications make it really fast and what's more: the temp files are avoided completely (this obviously has wider implications than performance by itself). -- meyergru _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
