This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ntoronto
Recipients arkanes, christian.heimes, gvanrossum, ntoronto
Date 2007-12-01.23:00:53
SpamBayes Score 0.000388134
Marked as misclassified No
Message-id <1196550063.99.0.616994592295.issue1518@psf.upfronthosting.co.za>
In-reply-to
Content
I've attached the latest patch, which should fix the build and compile
problems on Windows. It also passes test_gc - I changed test_gc after
verifying that it was working correctly. (There are now four objects to
collect rather than two.) On my systems this passes all regression tests
that aren't skipped.

The patch also includes a new fastglobals_test.py, which has a few extra
benchmarks.

Benchmark results for both of my systems are here:

http://spreadsheets.google.com/ccc?key=pHIJrYc_pnIVGXyUxWYFkLw&hl=en_US

This covers pystones, pyfastglobals_test, and pybench. In the latter
two, operations that have been most directly affected by the patch are
in red.

Pystones is significantly faster. The other two show that the operations
that aren't supposed to be affected aren't significantly in one
direction or the other (at least on these two systems). In pybench, an
average run is just a bit faster. I tested -O2 as well to verify that
changes in performance aren't due to accidental optimization differences.

I added the three new parser minibenchmarks to see what would happen to
normal, idiomatic Python code. I was surprised that it wasn't much
better, what with all the xranges and lens and accessing a global
variable all the time. Since this patch makes globals and builtins
almost as fast as locals and doesn't slow anything else down, we might
conclude that global and builtlin lookup has a lower impact on overall
performance than most of us assumed. However, I'm still keen on the
patch for two reasons (besides the fact that I wrote it :D):

1. It gets rid of the "_len = len" anti-pattern. The obvious way to
access globals and builtins is just as fast.

2. It lays down a framework for speeding up class attribute access.

What I mean by #2 is that _PyType_Lookup (looking up a method attribute)
can be very slow when looking up inherited methods. I think I can make
it take a near constant amount of time no matter how deep the
inheritance hierarchy is. I think it would only take a per-class adapter
(like PyFastGlobalsObject) that lazily caches class dict entry pointers
to methods and clears itself if the MRO changes.

Not today, though. :)
Files
File name Uploaded
fastglobals-1.patch.txt ntoronto, 2007-12-01.23:00:54
History
Date User Action Args
2007-12-01 23:01:04ntorontosetspambayes_score: 0.000388134 -> 0.000388134
recipients: + ntoronto, gvanrossum, christian.heimes, arkanes
2007-12-01 23:01:04ntorontosetspambayes_score: 0.000388134 -> 0.000388134
messageid: <1196550063.99.0.616994592295.issue1518@psf.upfronthosting.co.za>
2007-12-01 23:01:03ntorontolinkissue1518 messages
2007-12-01 23:01:01ntorontocreate