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

Slowness while debugging objects with slow repr



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?

Later: I confirm that having the mysql server on localhost is a complete game changer.

[Zooba: This is because the object representing a query is actually running the query when we call repr on it. The real fix is to fix the object so it doesn't do this, but we should also look into some way to prevent the problem becoming so bad it causes complaints.]


Zooba wrote May 14, 2014 at 4:54 PM

We may be able to add some self-profiling to detect when repr is slow. For example:
  1. Always time visualstudio_py_debugger.Thread.collect_variables
  2. If it exceeds a certain threshold (1s?), enable per-type profiling
  3. For any type that has a max/mean/min repr above a certain threshold (0.5s?), switch to always using object.__repr__
Alternatively, we could provide a simpler way for the user to specify types that we should not repr. However, due to search paths and import issues, I suspect that profiling would be simpler.

pminaev wrote May 14, 2014 at 5:48 PM

I wonder if this is actually due to the fix for - among other things, it will call len() on collections to determine whether they're small enough to repr() safely, and I can see how this would trigger running the query against the DB in this case.