Debugging speed

Sep 6, 2013 at 12:03 AM
I compared the speed of code running under the debugger (clicking on the green Start arrow ) and not running under the debugger (clicking on Start without debugging). The latter was five times faster. Is this normal?

This has turned into a major headache. Any insights?

Thanks.
Coordinator
Sep 6, 2013 at 12:29 AM
Yes, this is a known issue with well-understood reasons. We have a bug tracking this:
https://pytools.codeplex.com/workitem/576

And here's a recent discussion on why it's happening and what to do about it - you might find it interesting, and might want to try some of the workarounds suggested in the more recent posts:
https://pytools.codeplex.com/discussions/271752
Sep 6, 2013 at 3:00 AM
I wonder if there is a way to run a portion of the code that I know works well without debugging and then switching to debug mode only for the final portion that may have problems. In R I could insert a browser() statement in the code and it would run normally up to that point. Is there something similar under Python or even better, IPython?
Coordinator
Sep 6, 2013 at 4:24 AM
There's nothing exactly like that, but you can achieve a similar effect by writing your code such that it prints a notification and pauses once it reaches the desired point, and then attaching the debugger to it at that point (Ctrl+F5 is the usual shortcut to run without debugger, and you can attach via Debug -> Attach to Process).
Sep 26, 2013 at 5:09 PM
Thanks for the reply. I am still trying.

I inserted the statement

input('\nPress ENTER to exit')

in my code and hit CTRL+F5. Execution stopped there. I then did Debug/Attach to Process and attached the only python.exe entry. Then I went back to the window where the process was running and hit Enter. The program continued running to the end, even though I had set a breakpoint in the editor after the input statement.

Is there a place where I can read more about this procedure? I think I am missing something.

Thanks for the help.
Coordinator
Sep 26, 2013 at 5:32 PM
Was the line after input a blank line, by chance? If so, you might be hitting https://pytools.codeplex.com/workitem/26

Also, when attaching, can you confirm that you have attached using the Python code type (as shown in the Attach to Process window)? The default should be automatic detection, and it should say "Automatic (Python)" when you highlight python.exe; but if you have previously changed the type to something else, that choice will stick.
Sep 26, 2013 at 6:17 PM
I changed my code so that there is a breakpoint (red ball) on the line immediately after the input(...) statement.

I also checked that automatic detection was saying "Automatic (Python)" and I also tried choosing Python manually.

I also tried attaching to cmd.exe, which is the title of the window where the code is running.

None of these things worked.

I think I read a while ago that attaching the debugger needed symbols. Is that the problem?

Thanks again.

FS
Coordinator
Sep 26, 2013 at 6:27 PM
Attaching to Python does not require symbols, as it is not a compiled language. We do need symbols for the Python interpreter when you're doing mixed-mode debugging (i.e. debugging both Python and C++ at the same time), but this should only be the case when you select some other code type in addition to Python in the Attach to Process dialog. This will never be the case for automatic code type detection.

I've noticed something about your code:
input('\nPress ENTER to exit') 
If you're using Python 2.7, and you really just press Enter in response to the prompt, then input() will raise SyntaxError (because it expects a valid Python expression, and empty string isn't one). Naturally, the following line will not be hit then. raw_input() would be the function to use in this case.

Also, you shouldn't really need a breakpoint. You should be able to attach and then tell the debugger to pause from VS. It won't pause until it executed the next line of Python code, so you'll still need to enter something for [raw_]input() to return, but it should break on the next line after that.
Sep 26, 2013 at 7:24 PM
I am running version 3.2.2.

Do I need to attach cmd.exe or python.exe? (I tried both)

Does PTVS confirm that the attachment was successful? (Nothing happened on the screen except for some blinking after I Ok'd the attachment)

How do I tell the debugger to pause from VS?

Thanks again.

FS
Coordinator
Sep 26, 2013 at 8:46 PM
You need to attach to python.exe. I'm not sure where cmd.exe comes from, but it may be that your script is trying to run some shell code?

When attachment is successful, you should see VS switch to debugging mode. This should be particularly obvious from the toolbars - you should see a new one appear that will have icons for continue/stop/pause on it. If you can't find these on a toolbar for whatever reason, then they should also be available in the Debug menu.

To check that Python in particular has been successfully attached to, you can try opening the Modules window (Debug -> Windows -> Modules), and checking that the Python modules that you're using appear there.
Coordinator
Sep 26, 2013 at 9:21 PM
cmd.exe comes from us - we use it so we can add a pause at the end of the program. But python.exe is indeed the correct process to attach to.
Sep 26, 2013 at 10:19 PM
It is working now, I believe the problem was that the statement immediately after the input(...) statement was a print(...) statement. Actually setting breakpoints on print() statements seem to be Ok as long as the print() statements are not located immediately after the input() statement (or if there are only blank lines between the input() statement and the print() statement). When I put two breakpoints on two print() statements, the first one being immediately after the input() statement, execution stopped in the second print() statement, not on the first.

However, in all cases the Modules window remains empty, even when the breakpoint is not in the main module.

This has been a great step forward. Debugging will be much faster from now on. Many thanks for the help and the patience.
Coordinator
Sep 26, 2013 at 10:56 PM
Actually setting breakpoints on print() statements seem to be Ok as long as the print() statements are not located immediately after the input() statement (or if there are only blank lines between the input() statement and the print() statement). When I put two breakpoints on two print() statements, the first one being immediately after the input() statement, execution stopped in the second print() statement, not on the first.
This is really strange, and I cannot reproduce it locally on 3.3.2 - but, as described, it's clearly a bug. Can you post the code snippet with input and prints?
However, in all cases the Modules window remains empty, even when the breakpoint is not in the main module.
A further mystery. Even if you don't import anything, you should still, at the minimum, see the startup module of your program there.

Can you clarify whether you're using mixed-mode debugging or not?
Sep 26, 2013 at 11:23 PM
Ok, here is the code:

Code starts here

input('\nPress ENTER to start debugging')
print('Will it stop here?') # (There is a breakpoint (red ball) on this line)

x = 1 # No, it stops here!! (There is another breakpoint (red ball) on this line)
y = 0

Code ends here

Here is the sequence of actions:

1) Create a file test.py with the code above, add to project.
2) In the Solution Explorer right-click on test.py and click on Set as Startup File.
3) Hit CTRL+F5.
4) A window with the title C:\Windows\System32\cmd.exe pops up. Within the window there is the text "Press ENTER to start debugging" (and nothing else).
5) In VS click on Debug (the one on top), Attach Process. A window with the title Attach to Process pops up. In the field Available Processes scroll down, click on python.exe (there is only one process with this name) and then click on the Attach button.
6) Move back to the cmd.exe window and hit ENTER.
7) Back in VS a yellow arrow appears in front of the line with the "x = 1" code. The print() line is executed: the text "Will it stop here?" appears in the cmd.exe window.
8) Click on the StepOver button, the line with "x = 1" is executed. This can be checked by hovering with the mouse pointer over the symbol "x". The yellow arrow moves to the next line.
9) Click again on the StepOver button, the line with "y = 0" is executed. This can be checked by hovering with the mouse pointer over the symbol "y". The yellow arrow moves to the next line.
10) Click on Debug (the top one), Windows, Modules. The Modules window opens but it contains only the titles Name, Path, Optimized, etc. There are no entries below the titles.

I am not using mixed-mode debugging.

Hope that helps.
Coordinator
Sep 27, 2013 at 1:28 AM
Yep, I can repro now. The key part to it is attaching; regular F5 run hits all breakpoints as usual. I'll take a look at what's going on there. Thanks!