Es scheint, dass IronPython 2.0.1 eine Skriptdatei etwa 3x langsamer als IronPython 1.x ausführt. Ich bin nicht überzeugt, dass es nicht etwas ist, was ich tue, also frage ich mich, ob andere ähnliche Erfahrungen gemacht haben.IronPython 2.0 führt Code langsam
Ich habe ein 200k Python-Skript, das dauert 5 Sekunden aus einer Datei auf IP 1.x und fast 18 Sekunden in IP 2.0.1 auszuführen!
Enthalten Ihre Zeitangaben die Startzeit? IronPython 2.6 Beta hat die Startzeit und das Kompilieren/Ausführen von Code radikal verbessert. Ich schlage vor, dass Sie diese Freigabe versuchen, wenn Sie können.
Cheers, Davy
Es gibt definitiv einige Dinge, die in IronPython langsamer sind als in Python. Das liegt oft daran, dass Sie in der Implementierung einen seltsamen Eckfall treffen. Es lohnt sich, es auf ein sehr einfaches Skript zu reduzieren, das den Leistungsunterschied zeigt und das an die IronPython mailing list sendet - die Entwickler sind sehr reaktionsschnell.
In letzter Zeit gab es eine Reihe von interessanten Blogposts über die Leistung von IronPython - this is a good overview. Die Zusammenfassung ist, dass Sie sehr gute Leistung erhalten können, sobald Sie die Fallstricke vermeiden, und das IP-Team ist sehr daran interessiert, diese Probleme zu erkennen und schnell zu beheben. Einen Repro zu verengen, um die Fallgrube zu finden, ist der schwierigste Teil - sobald Sie herausgefunden haben, was das Verhalten auslöst, ist es im Allgemeinen einfach, zu umgehen.
Danke, eigentlich spreche ich über eine scheinbar große Perf Unterschied zwischen IronPython 1 (Pre-dlr) und IronPython 2. nicht CPython und IronPython. Allerdings war die Performance-Übersicht von Python, IP und Jython sehr informativ. Vielen Dank. – logan
Ah, richtig. Eigentlich gilt alles, was ich gesagt habe, um Leistungsregressionen von IP 1 auf IP 2 zu isolieren - zum Beispiel war die Arbeit bei der Portierung von Resolver One auf IP 2 ein Problem dieser Art und arbeitete mit dem Entwicklerteam zusammen, um das Problem zu diagnostizieren Ursache. – babbageclunk
Wir sahen auf jeden Fall merkwürdige Leistungsverschlechterungen (von 1 bis 2) an Orten, wo es so aussah, als ob wir nicht mit dem Problem in Verbindung gebracht werden könnten. Viele von ihnen schienen Folgen der architektonischen Veränderungen bei der Extraktion des DLR und Optimierungstechniken zu sein. Dino und das Team waren sehr hilfreich bei der Ausarbeitung des Geschehens. – babbageclunk
Ich hatte auch ein ähnliches Problem, als ich begann, IronPython 2.0 zu verwenden. Das Problem für mich war die düstere Startzeit für das DLR. Sobald die Laufzeit geladen ist, ist die Skriptleistung einigermaßen schnell.
Um die Startzeit für die Laufzeit zu reduzieren, können Sie versuchen NGEN'ing the binaries. Dies reduzierte die Startzeit um 60% für mich.
Auch mit diesem Fix ist es relativ relativ schnell noch nicht so schnell. Wenn Ihr Skript nicht viel leistet, wird der Start trotzdem einen erheblichen Teil der Gesamtzeit beanspruchen. Hoffentlich wird das DLR-Team bald die Startup-Performance-Probleme beheben.
Hinweis: Ich vermute, dass die DLR-Startzeit in eingebetteten Szenarios, in denen die Laufzeitumgebung einmal geladen und wiederverwendet wird, kein großes Problem darstellt. Wenn es Ihre Lösung zulässt, können Sie versuchen, die Runtime zu hosten und Skripts von ihr zu starten. – DSO
Ich hosste die Laufzeit in einer C# -App. Der Flaschenhals ist wenn ich rufe ausführen. Sobald der Code anfänglich analysiert wurde, ist die Leistung akzeptabel. – logan
Wie sich herausstellt ... ist die Startzeit in eingebetteten Szenarien ebenfalls ein Problem. Ich habe auf 2.6B1 aufgerüstet und mein Problem wurde behoben. – logan
können Sie den Artikel lesen IronPython: Reusing Import Symbols to Avoid Performance Hits, die die eingebetteten Szenarien laufen schneller machen.
2.0.1 Startzeit war das Problem.Vielen Dank. Ich hoffe, dass das Beta-Tag "Management" lol nicht erschrecken. – logan