[IronPython] Weird performance issue
dinov at microsoft.com
Tue Jan 6 20:24:59 CET 2009
I think we are thrashing the hash code call site in CommonDictionaryStorage.HashSite._HashSite. Alternately it could be the equals call site in PythonContext._equalRetBoolSite. Similar to the property issue you can look at the call site object and see if it's going to the fixed read-only EmptyRuleSet.
We can probably add 2 sites which are per-dictionary but we might need to do something more clever as that could regress general dictionary perf.
The DLR team is going to be looking into general issues with understanding what's going on with call sites. Yesterday I pointed out performance investigations as being something important for them to look at.
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Glenn Jones
Sent: Tuesday, January 06, 2009 6:07 AM
To: Discussion of IronPython
Subject: [IronPython] Weird performance issue
More from the Resolver One upgrade:
We are seeing several performance failures in our tests, which we expect because the performance profile of IPy2 is different to IPy1. There is one that is perplexing and we hope that someone can give us some insight into possible causes for us to investigate.
One of our performance tests only fails when it is preceded by other tests. There is (as far as we can tell) no shared state between the tests. After much poking around, we discovered that replacing a set with a list caused the performance to improve from ~700ms down to ~100ms. We have been unable get a minimal repro, so far. Here's a little more detail on the how the code works:
def run(arg1, arg2):
* do some stuff
s = set()
* do stuff that populates s
We create a Thing and call run so that the set contains an entry, if we then create a new Thing and call the run method it takes 10 times longer than expected.
If we change s = set to s =  (and convert s.add to s.append, where appropriate), and do the same as above, the second call to run behaves as we expect. There is (at least in our code) nothing shared between the first call to run and the second call.
Does anyone have any ideas about where we can look to work out what's happening? Any suggestions for ways to diagnose this?
Glenn & Kamil
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ironpython-users