Martin v. Löwis <mar...@v.loewis.de> added the comment: > http://lwn.net/Articles/216948/ > Why kernel.org is slow
That's all independent of the issue at hand. Whether or not getdents is slow doesn't really matter here because we need to call getdents, anyway: it's the only API to get at the directory contents, iterative or not. The issue at hand is whether xlistdir actually provides any advantages to a real application, and that cannot be answered by looking at benchmarking results that benchmarked the kernel. The *only* way to determine whether xlistdir will help is to measure it in a real application. I stand by my claim that a) in cases where you use listdir, you typically have to consider all file names in the directory eventually. The total number of getdents calls to be made doesn't change when you switch from listdir to xlistdir (except in non-realistic micro-benchmarks). The cases that you don't need to look at all file names are typically dealt with by knowing the file name in advance (or perhaps a few alternative spellings it may have), and hence you don't use listdir at all (but stat/open). b) If there is some real-world processing of the files (e.g. at least to look at the file modification time), this processing (and the IO that goes along with it) by far outweigh the cost of reading the directory. So even if you could speed up listdir by making it iterative, the overall gain would be very small. There are also good reasons *not* to add xlistdir, primarily to avoid user confusion. If xlistdir was added, all peope would run off and change all applications of listdir "because it is faster", and have then to deal with backwards compatibility, even though in most applications, a single getdents call will fetch the entire directory contents just fine (and hence there is *no* change in xlistdir, except that the list is not created which uses a few dozen bytes). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11406> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com