There is one difference between pre-compiled & compiled at runtime: Global accesses will be a little bit slower with compiled files. That's because the files need to support being loaded into multiple ScriptRuntime's where if we compile it they don't. Other than that they should be basically the same.
I would expect properties to be a little slower than methods. The reason is that we first dispatch to the property descriptor, and then it dispatches to the function. But I think the perf fix will actually improve this somewhat as well. > -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of Orestis Markou > Sent: Wednesday, December 17, 2008 10:16 AM > To: Discussion of IronPython > Subject: Re: [IronPython] weird performance issue > > Also: It seems that even normal properties are slower than methods. > This > became apparent when we had property access in tight loops. The weird > thing is that this also happens only when using compiled dlls. > > Is there something inherently different with compiled python files? > Perhaps some optimization not kicking in? > > Kamil Dworakowski wrote: > > Thanks Dino, it looks like you are right. I print whenever > > _supportAdding == false. > > It happens a lot with the snippet executed, whereas it doesn't happen > > at all with > > the snippet commented out. > > > > We also discovered that the slow down only occurs when we compile > code > > to dlls (no _supportAdding == false if runned from sources). > > Still can't come up with a repro though. If you provide us with a > patch, we can > > test if it solves the problem in our code. > > > > As a short term solution we have removed all the properties from > > decorated functions. This fixed one performance test. We moved to > > other performance tests and we still see that some functions are > > slower when executed from dlls, so the same slow down might be > > triggered by sth else. > > > > On Wed, Dec 17, 2008 at 3:21 AM, Dino Viehland <di...@microsoft.com> > wrote: > >> My guess would be that we're pushing the > PythonContext._callSplatSite outside of the sweet spot in DLR site > caches. > >> > >> You could check this by putting a breakpoint in > PythonContext.Call(object, params object[]). Then look and see if > _callSplatSite._rules is an instance of EmptyRuleSet<T> with > _supportAdding == false. > >> > >> If this is the cause it should be pretty easy to fix - property's > should probably get their own call site object so it'll be specialized > to the specific property (maybe we could share a common one of the > function is a PythonFunction as these generate highly shareable calls > between multiple function instances). We're also doing a params call > today which we could stop doing and get a nice perf boost on > properties. > >> > >>> -----Original Message----- > >>> From: users-boun...@lists.ironpython.com [mailto:users- > >>> boun...@lists.ironpython.com] On Behalf Of Kamil Dworakowski > >>> Sent: Tuesday, December 16, 2008 11:08 AM > >>> To: users@lists.ironpython.com > >>> Subject: [IronPython] weird performance issue > >>> > >>> We see a very strange side effect of running the follwing code on > the > >>> performance of recalculations in Resolver One. > >>> > >>> def Dumbcorator(fn): > >>> def _inner(self, *args): > >>> return fn(self, *args) > >>> return _inner > >>> > >>> class Locker(object): > >>> @property > >>> @Dumbcorator > >>> def thing(self): > >>> return 2 > >>> > >>> l = Locker() > >>> l.thing > >>> > >>> Specifically, one of the performance test reports results 4 to 8 > times > >>> worse with this snippet in than without (the clock is turned on > after > >>> this snippet executes). If I comment out this snippet from the > code, > >>> it suddenly runs 4 to 8 times faster. The fact that I can comment > it > >>> out means that it is not used in the test, so it is bizzare that it > >>> slows it down. > >>> > >>> We can't reproduce the slow down in a clean example though. I hope > >>> something clicks for somebody and gives me a hint as to what is > going > >>> on. Tomorrow I'll continue on trying to minimize the code that is > >>> being slowed down, and hopefully come up with some decent repro. > >>> _______________________________________________ > >>> Users mailing list > >>> Users@lists.ironpython.com > >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> _______________________________________________ > >> Users mailing list > >> Users@lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > > _______________________________________________ > > Users mailing list > > Users@lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- > Orestis Markou > Software Engineer, > Resolver Systems Ltd. > ores...@resolversystems.com > +44 (0) 20 7253 6372 > > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
