Philip Meyer;547645 Wrote: > > >In my mind the jury is still out on which one will offer better > >performance with large libraries. No doubt scanning will always be > >much faster with SQLite > > Why do you say that? Most of the scanning time is reading files from > disk and interpretting the tag content (or importing from MusicIP or > iTunes) and then just writing rows to DB tables. > I don't see any obvious reasons for SQLite being much faster. Both > engines have to write to disk.
I think it was somewhat speculative, but Andy commented a while back that he thought it was probably because SQLite works within the SbS process itself, so there's no interprocess communication necessary, as there is with MySQL. During a scan there are a very large number of database read queries being performed, and eliminating all the interprocess communication greatly speeds up scan times. The performance benefits seem to be of much less consequence when performing tasks requiring only a few queries. Optimizing the MySQL setup does help a lot, but in my experience the performance increase for scanning is nowhere near what I've seen from the change to SQLite. Here's a SQLite tool that isn't half bad. You can't connect to the SQLite 'server', as there is no server - it requires access to the SQLite database itself. Maybe the bigger problem now is that SbS exclusively locks the SQLite database, so you must first unlock it before you can connect to it. 'SQLite Expert' (http://www.sqliteexpert.com) -- JJZolx Jim ------------------------------------------------------------------------ JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=77312 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
