Hi Ben, On Mon, 9 Mar 2015 at 21:58 Ben Hoyt <benh...@gmail.com> wrote:
> Note that this benchmark is invalid for a couple of reasons. (...) > Thanks a lot for the guidance Ben, greatly appreciated. Just starting to take an interest in the development of CPython and so something like running a benchmark seemed like a good a place as any to start. Since I want to get comfortable with compiling from source I tried this again. Instead of applying the patch, since the issue is now closed, I just compiled from the tip of the default branch which at the time was 94920:0469af231d22. I also didn't configure with --with-pydebug. Here are the new results: *Ryans-MacBook-Pro:cpython rstuart$ ./python.exe ~/Workspace/python/scandir/benchmark.py* Using Python 3.5's builtin os.scandir() Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 1/3... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 2/3... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 3/3... os.walk took 0.061s, scandir.walk took 0.012s -- 5.2x as fast *Ryans-MacBook-Pro:cpython rstuart$ ./python.exe ~/Workspace/python/scandir/benchmark.py -s* Using Python 3.5's builtin os.scandir() Comparing against builtin version of os.walk() Priming the system's cache... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 1/3... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 2/3... Benchmarking walks on /Users/rstuart/Workspace/python/scandir/benchtree, repeat 3/3... os.walk size 23400, scandir.walk size 23400 -- equal os.walk took 0.109s, scandir.walk took 0.049s -- 2.2x as fast This is on a Retina Mid 2012 MacBook Pro with an SSD. Cheers > you're compiling Python in debug mode (--with-pydebug), which produces > significantly slower code in my tests -- for example, on Windows > benchmark.py is about twice as slow when Python is compiled in debug > mode. > > Second, as the output above shows, benchmark.py is "Using slower > ctypes version of scandir" and not a C version at all. If os.scandir() > is available, benchmark.py should use that, so there's something wrong > here -- maybe the patch didn't apply correctly or maybe you're testing > with a different version of Python than the one you built? > > In any case, the easiest way to test it now is to download Python 3.5 > alpha 2 which just came out: > https://www.python.org/downloads/release/python-350a2/ > > I just tried this on my Mac Mini (i5 2.3GHz, 2 GB RAM, HFS+ on > rotational drive) and got the following results: > > Using Python 3.5's builtin os.scandir() > Comparing against builtin version of os.walk() > Priming the system's cache... > Benchmarking walks on benchtree, repeat 1/3... > Benchmarking walks on benchtree, repeat 2/3... > Benchmarking walks on benchtree, repeat 3/3... > os.walk took 0.074s, scandir.walk took 0.016s -- 4.7x as fast > > > I then did ./python.exe ~/Workspace/python/scandir/benchmark.py -s and > got: > > Also note that "benchmark.py -s" tests the system os.walk() against a > get_tree_size() function using scandir's DirEntry.stat().st_size, > which provides huge gains on Windows (because stat().st_size doesn't > require on OS call) but only modest gains on POSIX systems, which > still require an OS stat call to get the size (though not the file > type, so at least it's only one stat call). I get "2.2x as fast" on my > Mac for "benchmark.py -s". > > -Ben >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
