[wingide-users] wing import is very slow in debug mode

Jeremy Lewi jlewi at intellisis.com
Mon Jun 7 19:09:29 MDT 2010


It looks like a major bottleneck was simply the fact that I had a lot of
breakpoints set that weren't being hit (i.e leftovers from past debugging).
Deleting those breakpoints gave me a significant speedup. Its still slower
than non-debug but I'm willing to accept that's normal debugger overhead.

Thank you for the quick response. 


-----Original Message-----
From: Wingware Support [mailto:support at wingware.com] 
Sent: Sunday, June 06, 2010 8:22 PM
To: Jeremy Lewi
Cc: wingide-users at wingware.com
Subject: Re: [wingide-users] wing import is very slow in debug mode

Jeremy Lewi wrote:
> I'm running wing in debug mode and it takes a long time to import all 
> of the modules at the start of the script I'm doing e.g my script 
> looks like this
> Import package
> Print "done importing"
> Wing is very slow getting to the print statement.
> I think this is very slow because wing is loading up and analyzing a 
> whole bunch of modules in package which is bogging down the startup 
> process. For example, the little status bar says something like ~700 
> modules are loaded. "package" refers to a python package in my workspace.
> "package" is large but probably not larger than numpy or scipy and yet 
> "import package" seems to be taking a lot longer than importing numpy.
> I think it's a wing issue because I've tried issuing the same imports 
> from ipython and they happen pretty instantaneously so I think it's 
> the hooks/analysis that wing's import is doing.
> Any suggestions about how to speed things up?

How slow is slower, comparing with and without debug? I'm just wondering 
if it's within normal debugger overhead or not..

I should note that it's probably not the number of modules so much as 
the amount of pure Python code that they are executing during the 
import. It could very well be a single module doing some work in nested 
loops or something similar. The amount of overhead from the debugger is 
proportional to the number of byte codes executed and it appears worse 
if more work is being done by the interpreter actually executing byte 
codes and less is done by C code behind the scenes in the Python 
implementation or standard library.

For example, if you were to iterate through a string character by 
character in Python to find the first 'x' it would be a lot of byte 
codes while mystring.find('x') is only about two because the actual find 
loop is in C.

So it may be possible to narrow down where this is happening and work 
around it or optimize it.

> I tried using wingdbstub.debugger.StartDebug() to start the program 
> externally and then break into it; this seemed to help but I'm 
> wondering if that is the best solution?

It is the best solution if you're looking at a large amount of startup 
overhead that you can't avoid. If you just place the 'import wingdbstub' 
after the import, you should be all set (no need to call StartDebug as 
the position of the import defines when debug is started). If you want 
to debug code before the import and after, then you can get into calling 
SuspectDebug and ResumeDebug.

Please let me know if this does not help.



Stephan Deibel
Wingware | Python IDE
Advancing Software Development


More information about the wingide-users mailing list