Hi List,
I'm embarking on a project to rewrite a DLL that my team uses. It's a
COM DLL, and has to implement specific interfaces. Currently, it's
written in C++, which I am not terribly proficient with. However, it's
important that the code is as well tested and stable as possible. As
such, I thou
Hi all,
I am investigating performance problems we have when running our code using
IPy2b5 (comparing to IPy 1.1.1).
Found two interesting issues:
1. It seems that there is some bug in the 'sort' method
Running the following code:
from System import DateTime
def test():
s = Date
Every time you call sort, we create a new call site object which needs to be
spun up. So your test is really an absolute worst-case as far as
performance goes. Is it actually reflective of the circumstances under
which you do sorting, where the number of sorts vastly exceeds the size of
each sort
Thanks for the quick reply.
Today we do many 'little' sorts, since we have a sort call in an object's
__init__. However we might be able to avoid it.
I do not understand what constitutes a distinct call site. Can you give some
more details on this?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PRO
The short answer to this is "no".
I suspect it might be possible to implement predefined COM interfaces from
IronPython and to use COM-.NET interop to make this code visible to COM
consumers. But to actually create a DLL that can be loaded by the COM
loader would require a greater level of control
Ok, upon looking into this some more, I'm sad to say it looks like this won't
work right now :(. We need to figure out a way to run the serialization for
just the base class and how to do that isn't entirely obvious - so it probably
won't make 2.0. I've opened a bug to track the issue though:
Thanks Curt. It would have been a nice solution, but I will make do.
Alec
On Tue, Oct 7, 2008 at 1:38 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:
> The short answer to this is "no".
> I suspect it might be possible to implement predefined COM interfaces from
> IronPython and to use COM-.NET i
A dynamic call site is the fundamental unit of dynamic dispatch in the DLR.
The first time a call (such as __cmp__) goes through the site, we have to
do the work of figuring out exactly what code is going to run. The next
time the site is used, if the types of the arguments are the same then the
FYI after fixing this it looks like 2.0 is about 2x faster on my machine:
10:51:23.06
C:\Product\0\Merlin\Main > ipyr x.py
0.100372393698
10:51:46.32
C:\Product\0\Merlin\Main > C:\Product\Released\IronPython-1.1\ipy.exe x.py
0.222078504391
(note I'm using time.clock() which is more precise than
2008/10/7 Dino Viehland <[EMAIL PROTECTED]>:
> I took a look and we're spending most of our time doing old instance/old
> class accesses. If they used new-style classes it would probably run faster
> - although CPython might as well :) It seems like a good chunk of that is
> coming from __eq__
2008/10/8 Seo Sanghyeon <[EMAIL PROTECTED]>:
> Since this is clearly beneficial, I mailed the author a patch to make
> old-style->new-style change.
It has been applied.
http://yieldprolog.svn.sourceforge.net/viewvc/yieldprolog?view=rev&revision=887
--
Seo Sanghyeon
__
Cool, it then looks like the next biggest bottleneck is our isinstance
implementation (taking about 20% of the time). Certainly seems like something
that deserves optimization and I can probably make some easy improvements and
get them into 2.0.
-Original Message-
From: [EMAIL PROTECTE
Hi All,
Basic Repro is...
-form.py---
import clr
clr.AddReference('System.Windows.Forms')
from System.Windows.Forms import *
print len(dir(Form))
-test.py
from forms import *
print len(dir(Form))
Output:
538
443
My real world case is a subclass of Form is in another m
13 matches
Mail list logo
