2009-05-22 10 views
0

IronPython 2.0.1では、IronPython 1.xより3倍速くスクリプトファイルが実行されるようです。 私はそれが私がやっていることではないと確信していないので、他の人たちも同様の経験をしているのだろうかと思っています。IronPython 2.0でコードがゆっくり実行される

私は、IP 1.x上のファイルから5秒、IP 2.0.1内で約18秒かかる200kのpythonスクリプトを持っています!

答えて

0

タイミングに起動時間が含まれていますか? IronPython 2.6 Betaは、起動時間とコードのコンパイルと実行を大幅に改善しました。できるだけそのリリースを試してみることをお勧めします。

乾杯、 デイビー

+0

2.0.1起動時間が問題でした。どうもありがとうございました。 私はbetaタグが "管理"の笑いを恐れないことを願っています。 – logan

0

IronPythonではPythonよりもはるかに遅いものがあります。これは実装で奇妙なコーナーケースが発生していることが多いためです。パフォーマンスの差異を示す非常に単純なスクリプトに減らし、それをIronPython mailing listに送信することは価値があります。開発者は非常に反応的です。

IronPythonのパフォーマンスに関する最近のブログ記事は、this is a good overviewです。要約すると、落とし穴を避ければ、非常に優れたパフォーマンスを得ることができ、IPチームはこれらの問題を見つけて迅速に解決することに非常に関心があります。落とし穴を見つけるためにレトロを絞るのが最も難しい部分です。一度行動をトリガーすると、それを回避するのが一般的です。

+0

実際、IronPython 1(pre-dlr)とIronPython 2の間には、CPythonとIronPythonではなく、一見大きな違いがあります。それでも、Python、IP、Jythonのパフォーマンス概要は非常に参考になりました。ありがとう。 – logan

+0

ああ、そうです。実際、IP 1からIP 2への性能回帰を分離するために、私が言ったことはすべて真実です。例えば、Resolver OneをIP 2に移植する作業の多くは、この種の問題を発見していました。原因。 – babbageclunk

+0

実際にはメソッドディスパッチキャッシュのオーバーフローなどの問題が発生していることが判明したため、私たちが行っていたことが問題に関連していないような場所では、奇妙なパフォーマンスの低下が見られました(1から2へ)。それらの多くは、DLRの抽出におけるアーキテクチャーの変更、および最適化技術の結果であるように見えました。ディーノとチームは何が起こっていたのかを理解するのに非常に役立っていました。 – babbageclunk

0

IronPython 2.0を使い始めたときも同様の問題がありました。私にとっての問題は、DLRの劇的な起動時間でした。ランタイムが読み込まれると、スクリプトのパフォーマンスはかなり速くなります。

ランタイムの起動時間を短縮するには、NGEN'ing the binariesを試してみてください。これにより、起動時間が約60%短縮されました。

この修正プログラムを使用しても、まだそれほど高速ではありません。あなたのスクリプトがあまり進んでいない場合、スタートアップは依然として全体の時間のかなりの部分を占めます。うまくいけば、DLRチームはすぐにスタートアップのパフォーマンスの問題を修正します。

+0

DLRの起動時間は、ランタイムが一度ロードされて再使用される埋め込みシナリオではそれほど問題ではないと思われます。あなたの解決策が許せば、ランタイムをホストしてスクリプトを起動することができます。 – DSO

+0

私はC#アプリケーションの中でランタイムをホストしています。ボトルネックは私が実行を呼び出すときです。コードが最初に解析されると、パフォーマンスは許容されます。 – logan

+0

これは、組み込みシナリオでも起動時間が問題となることが判明したためです。私は2.6B1にアップグレードし、私の問題は修正されました。 – logan

関連する問題