New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore isinstance and issubclass speed in 2.6 #46786
Comments
This patch implements type.__instancecheck__ and type.__subclasscheck__, See also issue bpo-2303. Here are the performance figures for the current trunk version: Current SNV trunk: Using 2.6a1+ (trunk:62102, Apr 2 2008, 11:30:16) [MSC v.1500 32 bit Current trunk, patch applied: Using 2.6a1+ (trunk:62102M, Apr 2 2008, 11:21:32) [MSC v.1500 32 bit Python 2.5.2, for comparison: Using 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] |
I find similar speedups: isinstance(42, int) -2% (both negative ones are actually lower than original, but so low that it However, also I have an error in the test_exceptions.py suite: ====================================================================== Traceback (most recent call last):
File "Lib/test/test_exceptions.py", line 336, in testInfiniteRecursion
self.assertRaises(RuntimeError, g)
AssertionError: RuntimeError not raised Ran 10 tests in 0.031s FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_exceptions.py", line 351, in <module>
test_main()
File "Lib/test/test_exceptions.py", line 348, in test_main
run_unittest(ExceptionTests)
File "/home/facundo/devel/reps/python/trunk/Lib/test/test_support.py",
line 577, in run_unittest
_run_suite(suite)
File "/home/facundo/devel/reps/python/trunk/Lib/test/test_support.py",
line 560, in _run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_exceptions.py", line 336, in testInfiniteRecursion
self.assertRaises(RuntimeError, g)
AssertionError: RuntimeError not raised |
The test fails on this: def g():
try:
return g()
except ValueError:
return -1
self.assertRaises(RuntimeError, g) Changing that "return -1" to "return sys.exc_info()" shows that a Shallow testing of the new methods seem to show normal results, [Runtime,Value]Error.__[subclass,instance]check__([Runtime,Value]Error) is False for cross-checks and True otherwise. |
Running Daniels code interactively, with a debug build on Windows, I cannot see anything that is wrong with my code. Maybe this, and the Anyway, I attach a new, cleaner patch although this one still behaves in |
Thomas: I confirm your patch triggers this behavior. I can reliably get >>> def g():
... try:
... return g()
... except ValueError:
... return sys.exc_info()
...
>>> g()
(<type 'exceptions.RuntimeError'>, 'maximum recursion depth exceeded
while calling a Python object', <traceback object at 0xb7d9ba04>)
>>> import sys
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded in __subclasscheck__ I hope this helps... |
Problem found. See issue bpo-2542, which contains a patch that fixes the Exception RuntimeError: 'maximum recursion depth exceeded in |
speedup of this patch confirmed. Also, it triggers the bugs mentioned Its a big performance regression in 2.6 over 2.5 if we don't get this |
Can this patch go in? |
By the way, py3k suffers from this problem too, so a similar patch |
I'm currently doing the port to py3k. It makes me find interesting flaws |
Ok, here is the patch for py3k. As I said it fixes some interesting bugs The patch for trunk should probably be reworked or regenerated from the Performance numbers: timeit -s "val=ValueError(); cls=EOFError" "isinstance(val, cls)"
timeit -s "val=ValueError(); cls=EOFError" "isinstance(val, (cls,))"
timeit -s "val=ValueError; cls=EOFError" "issubclass(val, cls)"
timeit -s "val=ValueError; cls=EOFError" "issubclass(val, (cls,))"
pybench ("this" is with patch, "other" is without) Test minimum run-time average run-time |
New patch with a couple of tiny fixes. |
Here is the same patch, but backported to 2.6. |
+1 on applying this patch right away. For 2.6 and 3.0 to be successful, we need people to prefer to upgrade |
Both patches look correct to me, and I think they can be applied. |
Committed in r66042 and r66043. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: