This project has moved and is read-only. For the latest updates, please go here.

Slowness while debugging django views or templates

May 13, 2014 at 3:35 PM
Hello all,
I am new to django with PTVS and I am experiencing really painful slowness when hitting breakpoints or doing step-by-step debugging. My project is quite small (few python and template files).
I upgraded to VS 2013 update 2 + PTVS beta 1 and I still got the issue.
I know this is a recurrent issue but I still wonder where this comes from... Any idea to improve the situation is welcome!
May 13, 2014 at 5:17 PM
Hi Cyril

Are you able to link us to your project (or send it privately to We come across these sorts of issues from time to time and they are usually not caused by the same thing, so it really helps us if we can debug our tools while we're debugging the project and see what is happening internally.
May 14, 2014 at 2:54 PM
I stripped everything 'sensitive' from my project to make a clean one ready to share with you. The result is still slow to debug but it is bearable.
The sample project is available for download from here . Just set up a database in and sqlall to it.

It looks like with the full version of my project, hitting F10 to step through the code takes ~5 seconds (even on no-op lines), and makes the python console pop up back on top of the other windows and then go back to the background before visual studio comes back to life on the next line.

However after a bit more investigation, it looks like the slowness is directly related to the lag between the machine where I am debugging and the MySQL server. When the MySQL server is on localhost, the debugging experience is much better, even when debugging code that has nothing to do with the database. How can this be explained?

Thanks in advance,
May 14, 2014 at 4:20 PM
Do you have local variables that display the result of queries when you call repr(x)? If so, these are being evaluated on each step, which is why you are hitting the DB so often. (FWIW, these objects should not being doing this - accessing the DB for str() is okay, but repr() is only supposed to produce enough information to recreate the object, not the results.)

As a workaround, you can modify the file in your install directory (and I see I need to update that page for 2.1... I'm sure you'll find it :) ) and add a type check to SafeRepr._repr_obj. If you call object.__repr__(x) instead of repr(x), then it will quickly display something like '<Spam object at 0x00123456>' instead of going to the DB (or if it has some other method for displaying the query you can use that).

We should really come up with a way to specify these without having to modify the source code, but then again, this way you get the freedom to make arbitrary changes to the debugger :)
May 14, 2014 at 4:46 PM
I did not manage to hack (visual studio won't let me hit F5 any more) but I confirm that having the mysql server on localhost is a complete game changer.

It would definitely be cool to have a way to configure ptvs to control whether their representation should use repr or object.repr (at least globally, at best per-model) .

Thanks again,
May 14, 2014 at 4:49 PM
You can try running directly from a command line to see what the errors are (did you forget an import?). Hacking it is obviously unsupported, so most of our code assumes that it's just going to work...
May 14, 2014 at 4:51 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.