Jason Tackaberry wrote: > On Sun, 2006-04-23 at 12:59 +0200, Dirk Meyer wrote: >> Yes, the reason for that is that foo.srt may affect the metadata for >> foo.avi. But your listdir code now has a key list, maybe we can pass >> that to the results, too? In that case it should be faster to access >> all keys starting with the current basename. > > When you're talking about a common code path (like _scan), it's worth it > to maintain as many dicts as are necessary to avoid even O(n) where you > can. But O(n^2) is just wayyyy too much. On /usr/bin with 2192 files, > it must make 4804864 iterations to do a scan.
Any ideas to fix this? >> BTW, at the and of query_dir we do a >> |items.sort(lambda x,y: cmp(x.url, y.url)) >> >> The code make sure the the items are already sorted based on the name >> (not the url, which is a bit different). But I can't remeber why it >> could be a bad idea to just return a list of items sorted by name in >> this case. > > It'd definitely be nice to remove that sort if possible. On /usr/bin > that saves ~25000 invocations of that lambda :) Done, it should be ok. For other searches we still do a sort based on the url. But it doesn't has to be url, maybe a name, parent combination and maybe sqlite can help us return sorted results. Dischi -- Yesterday is history, Tomorrow is a mystery, Today is a gift. That's why it's called: The Present.
pgpEn0pjdWwY4.pgp
Description: PGP signature
