[wingide-users] wing import is very slow in debug mode
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.
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.
Wingware | Python IDE
Advancing Software Development
More information about the wingide-users