#8: I'm seeing a very different breakdown with my FiPy scripts on Mac OS X. Using time.time() embedded in the startup sequence for my script:
$ python r1082.py ... startup time: 4.54922485352 ---- $ python -m pdb r1082.py (Pdb) c ... startup time: 4.59463787079 ---- $ ipython -pydb In [1]: run -d -b 43 r1082.py ipydb> c ... startup time: 856.767014027 ---- In contrast, using ipdb (which I didn't know about before; thank you!): $ ipython ... In [1]: %run r1082.py ipdb> c ... startup time: 4.54875421524 ---- ipdb is a little clumsy to set up, but is quite usable. pydb is insane. > As for "don't be so slow" (with apologies if this is obvious): > * Use breakpoints (perhaps inside ad hoc "if" statements) to avoid > single-stepping unproblematic parts of code. My trouble, as above, is even getting to the code I want to single-step. > * Use pydb.set_trace()? (Never tried that.) Seems to work well, although if I'm going to do that, ipdb seems nicer. > * Are you using Numpy for the computationally intensive code? Amongst other things. > * If you are, Cython (www.cython.org; available for Mac too) might speed up elementwise calculations. I'm trying to *reduce* my debugging headaches! 8^) Cython is certainly on our list of optimizations to explore, but is not the solution here. My immediate problem is not with the speed of my own code, nor with normal debugging of my code; it's this 'curframe' business and pydb that's causing me grief. Now that I know about ipdb, I can get on with things, thanks. -- Cannot step debugger in IPython 0.9.1 under Python 2.6.2: Pdb instance has no attribute 'curframe' https://bugs.launchpad.net/bugs/381069 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
