>That scans are much faster with SQLite has been acknowledged. Is that *really* the case? I thought that much of the speed increase between 7.5.1 and 7.6 was due to a re-written compiled component, and in particular better libraries for file scanning and parsing tags? As no-one can reliably run a comparison in 7.6, I don't think SQLite has been acknowledged as the difference?
>Speculation is that it's the in-process nature of SQLite that makes an >operation requiring 100s of thousands queries much faster. > It doesn't sound right that there are 1000's of queries. I remember in the past the discussion of a re-write of the scanning for a new schema, and in particular a two-phase scan, where tags are read and held in separate tables, and then processing of the tag tables into a model for library browsing. One of the slow parts was apparently merging compilation tracks into albums, whereby there were 100's of track accesses, which I suggested an alternative way to do as a single statement/Stored Procedure call. I think SQLite may be faster, as it is generally better with write operations, and (full) scanning must be heavy on writes. However, it has also be observed that the default MySQL config is not optimal in many cases. My own MySQL instance performs much better than that offered by SBS defaults. And all in all, I'm not that bothered by scan performance, compared to browse library access. A scan for new/changed files is ~5 mins for me (most of which is file system access, I think), but often doesn't work, requiring a full scan (eg. to correct artwork, fix compilations after changing comp tags, etc). Fixing that scan to be more reliable (maybe already done in 7.6?), would make more difference. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
