poor IronPython performance of external modules when debugging enabled

I am running into some performance problems with IronPython inside of VS2010 while trying to import and use SymPy.

I have an IronPython test project containing the following code:

import time

print 'StandaloneIronPython'

startTime = time.time()
from sympy import *
importTime = time.time() - startTime
print 'Import time = %f' % importTime

startTime = time.time()
for x in (x/10.0 for x in xrange(-100,100)):
    (x**2-2*x)
numericsTime = time.time() - startTime
print 'Basic numerics time= %f' % numericsTime

startTime = time.time()
for x in (x/10.0 for x in xrange(-100,100)):
    N(x**2-2*x)
sympyTime = time.time() - startTime
print 'SymPy time = %f' % sympyTime

raw_input('Press enter to continue...')

SymPy was downloaded and installed as an egg; my "IronPytho开发者_StackOverflow中文版n 2.7\Lib\site-packages" folder is in the project Search Path.

If I run the program via "Debug > Start Debugging" I get approximately this:

StandaloneIronPython
Import time = 12.090019
Basic numerics time= 0.015594
SymPy time = 2.230804
Press enter to continue...

If, however, I run the program via "Debug > Start Without Debugging" I get approximately:

StandaloneIronPython
Import time = 2.199600
Basic numerics time= 0.015602
SymPy time = 0.140404
Press enter to continue...

I get ~5 times the speed importing and >10 times the speed running sympy.

So how can I get good performance out of IronPython if it's spending all its time debugging library code?

• Is there a way that I can bundle up SymPy as a library, assembly, or something else such that it will perform quickly?
• Is there a way to tell VS2010 not to debug the code for SymPy?
• Is there some other sort of solution?

Whenever you see a big performance discrepancy between running with and without a debugger attached, it's usually because your app is generating a ton of events that the debugger has to handle.

The most common example of this is exceptions. If SymPy is throwing and catching lots and lots of exceptions during initialization, each exception causes a round trip to the debugger (even if it's handled), causing a massive slowdown.

You can verify this by going to "Debug > Exceptions...", checking the "Thrown" box next to "Common Language Runtime Exceptions" and re-running the app. If you stop at hundreds of exceptions, there's your problem.

If that is indeed your problem, unfortunately there's not a good workaround for it. Pre-compiling your Python code into a .dll won't prevent those exceptions from being thrown.