traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
cpython/Lib/test/output/test_profile

21 lines
985 B
Plaintext
Raw Normal View History

Hopefully fix the profiler right. Add a test suite that checks that it deals correctly with some anomalous cases; according to this test suite I've fixed it right. The anomalous cases had to do with 'exception' events: these aren't generated when they would be most helpful, and the profiler has to work hard to recover the right information. The problems occur when C code (such as hasattr(), which is used as the example here) calls back into Python code and clears an exception raised by that Python code. Consider this example: def foo(): hasattr(obj, "bar") Where obj is an instance from a class like this: class C: def __getattr__(self, name): raise AttributeError The profiler sees the following sequence of events: call (foo) call (__getattr__) exception (in __getattr__) return (from foo) Previously, the profiler would assume the return event returned from __getattr__. An if statement checking for this condition and raising an exception was commented out... This version does the right thing.
2001-10-03 21:58:24 -03:00
test_profile
Enable the profiling of C functions (builtins and extensions)
2004-03-24 17:57:10 -04:00
74 function calls in 1.000 CPU seconds
Hopefully fix the profiler right. Add a test suite that checks that it deals correctly with some anomalous cases; according to this test suite I've fixed it right. The anomalous cases had to do with 'exception' events: these aren't generated when they would be most helpful, and the profiler has to work hard to recover the right information. The problems occur when C code (such as hasattr(), which is used as the example here) calls back into Python code and clears an exception raised by that Python code. Consider this example: def foo(): hasattr(obj, "bar") Where obj is an instance from a class like this: class C: def __getattr__(self, name): raise AttributeError The profiler sees the following sequence of events: call (foo) call (__getattr__) exception (in __getattr__) return (from foo) Previously, the profiler would assume the return event returned from __getattr__. An if statement checking for this condition and raising an exception was commented out... This version does the right thing.
2001-10-03 21:58:24 -03:00
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
Using repr() generates entries that the current stats package can't collate, so setting it back to the function name
2004-07-12 20:38:02 -03:00
12 0.000 0.000 0.012 0.001 :0(hasattr)
8 0.000 0.000 0.000 0.000 :0(range)
1 0.000 0.000 0.000 0.000 :0(setprofile)
Hopefully fix the profiler right. Add a test suite that checks that it deals correctly with some anomalous cases; according to this test suite I've fixed it right. The anomalous cases had to do with 'exception' events: these aren't generated when they would be most helpful, and the profiler has to work hard to recover the right information. The problems occur when C code (such as hasattr(), which is used as the example here) calls back into Python code and clears an exception raised by that Python code. Consider this example: def foo(): hasattr(obj, "bar") Where obj is an instance from a class like this: class C: def __getattr__(self, name): raise AttributeError The profiler sees the following sequence of events: call (foo) call (__getattr__) exception (in __getattr__) return (from foo) Previously, the profiler would assume the return event returned from __getattr__. An if statement checking for this condition and raising an exception was commented out... This version does the right thing.
2001-10-03 21:58:24 -03:00
1 0.000 0.000 1.000 1.000 <string>:1(?)
0 0.000 0.000 profile:0(profiler)
1 0.000 0.000 1.000 1.000 profile:0(testfunc())
Added global runctx function to profile to fix SF Bug #716587
2004-03-22 16:12:56 -04:00
1 0.400 0.400 1.000 1.000 test_profile.py:23(testfunc)
2 0.080 0.040 0.600 0.300 test_profile.py:32(helper)
4 0.116 0.029 0.120 0.030 test_profile.py:50(helper1)
8 0.312 0.039 0.400 0.050 test_profile.py:58(helper2)
8 0.064 0.008 0.080 0.010 test_profile.py:68(subhelper)
28 0.028 0.001 0.028 0.001 test_profile.py:80(__getattr__)
Hopefully fix the profiler right. Add a test suite that checks that it deals correctly with some anomalous cases; according to this test suite I've fixed it right. The anomalous cases had to do with 'exception' events: these aren't generated when they would be most helpful, and the profiler has to work hard to recover the right information. The problems occur when C code (such as hasattr(), which is used as the example here) calls back into Python code and clears an exception raised by that Python code. Consider this example: def foo(): hasattr(obj, "bar") Where obj is an instance from a class like this: class C: def __getattr__(self, name): raise AttributeError The profiler sees the following sequence of events: call (foo) call (__getattr__) exception (in __getattr__) return (from foo) Previously, the profiler would assume the return event returned from __getattr__. An if statement checking for this condition and raising an exception was commented out... This version does the right thing.
2001-10-03 21:58:24 -03:00