Geschwindigkeit des Importierens optimieren, Modulpfad setze

[Inmare]

Moin,
ich versuche auf einem Embedded System (Foxboard) mit dem THTTPD und CGI eine Python-Web-Konfigurationsoberfläche zu erstellen. An sich läuft auch alles, nur ist die Sache nicht besonders fix. Statische Inhalte werden schnell ausgeliefert. Ein Pythonskript ohne irgendwelche Importe braucht vielleicht zwei Sekunden; sobald aber importiert wird (CGI), werden etwa sieben Sekunden benötigt, ohne daß etwas von der eigentlichen Arbeit getan wäre. Das ist natürlich ein wenig zu langsam. Augenblicklich ist Python 2.4 im Einsatz.

Kann mir jemand einen Tip oder Ansatzpunkt geben, wo es noch Optimierungspotential geben könnte? Älteres und damit kleineres Python vielleicht? Ich benutze soweit keine Spezialitäten der neueren Versionen.

Es scheint auch, daß der aufgerufene Python-Interpreter die Werte von PYTHONPATH und PYTHONHOME nicht mitbekommt. Die Pfade muß ich daher bei jedem Seitenaufruf erstmal hinzufügen (import sys; sys.path.append('...')). Stattdessen enthält der Modulpfad Verweise auf nicht existierende Pfade und Zip-Dateien. Wie kann ich den Interpreter dauerhaft davon überzeugen, nur in ..../lib/python2.4, ..../lib/python2.4/lib-dynload und meinem eigenen Modulverzeichnis zu suchen?

Und als letztes: Welche Skripte werden denn kompiliert? Ich habe augenblicklich in cgi-bin einzelne Skripte für die Seiten sowie eines, das nur die Pfade setzt (dadurch habe ich das zentral an einer Stelle, es kann aber trotz fehlender Pfade von den Seiten gefunden werden). Kompiliert zu pyc wird nur das importierte Skript zum Setzen der Pfade, die direkt aufgerufenen Skripte für die Seiten nicht. Woran mag das liegen?

Vielen Dank.

[gerold]

ich versuche auf einem Embedded System (Foxboard) mit dem THTTPD und CGI
[...]
wo es noch Optimierungspotential geben könnte?
[...]
(import sys; sys.path.append('...'))
[...]
Kompiliert zu pyc wird nur das importierte Skript zum Setzen der Pfade, die direkt aufgerufenen Skripte für die Seiten nicht.

Hallo Inmare!

Willkommen im Python-Forum!

Bei CGI wird jedes mal der Python-Interpreter neu gestartet und alles wird immer neu imporitert. Das merkt man natürlich auf einem langsamen Embedded-Gerät. Es wäre vielleicht besser, nicht auf CGI zu setzen und stattdessen einen eigenen kleinen Python-Server laufen zu lassen. Komplett ohne THTTPD.

Es gibt zwei Möglichkeiten, die mir sinnvoll erscheinen.

1.) CherryPy http://www.cherrypy.org/ als Server heran zu ziehen. CherryPy wäre die einfachste Möglichkeit. Es würde als Server alle Daten zur Verfügung stellen und läuft im Hintergrund. Die Module werden nur beim Starten des Servers geladen. Danach verbleiben diese im Speicher. Das bringt mächtig Geschwindigkeit. Bei meinem Test braucht ein einfacher CherryPy-Webserver 8520kB im Speicher. Das ist für ein Embedded-Gerät sicher nicht wenig. Dafür lässt es sich einfach Entwickeln. Viel einfacher als direkt mit WSGI zu arbeiten.

2.) WSGI über das Python-Paket "wsgiref". Dieses Paket ist bei Python 2.5 mit dabei. Du kannst es aber auch mit Python 2.4 verwenden. WSGI ist nicht so einfach wie CherryPy, aber es hat den Vorteil, dass es weniger Speicher braucht. Wenn dir CherryPy zu viel Speicher braucht, dann würde ich es mit "wsgiref" versuchen. --> http://lucumr.pocoo.org/articles/gettin ... -with-wsgi
Dieses Beispiel braucht bei mir 5628kB im Speicher. Du sparst dir also ca. drei MB Speicher.

Wenn du statt ``import sys; sys.path.append('...')`` ``import sys; sys.path.insert(0, '...')`` schreibst, dann sucht Python gleich am Anfang im richtigen Ordner nach den Modulen. Das dürfte einiges an Zeit bringen.

Das Verhalten beim Kompilieren ist vollkommen normal. Es werden nur die zu importierenden Module kompiliert. Das wirkt sich in deinem Fall aber sicher nicht merkbar auf die Performance aus. Ignoriere es einfach.

Und jetzt ein paar Fragen an dich: Ich spiele mich mit dem Gedanken, mich mehr mit Embedded-Geräten (auf Linux-Basis) zu spielen. Einfach um dadurch mehr darüber zu lernen und evt. ein paar sinnvolle Anwendungsgebiete zu erschließen.

Dieses "Foxboard" sieht ja nicht schlecht aus. Kann man an dieses Foxboard auch eine Flash-Card (z.B. mit 1GB) als Speichermedium statt einer Festplatte anschließen? Kann man eine kleine Festplatte anschließen?

mfg
Gerold

[Inmare]

Hej,
danke für das Willkommen und die Hilfe.

Tja, die Entscheidung für Python/CGI kam nicht von mir... die Evaluation ("Python und CGI läuft") ist von anderen vorgenommen worden. Dabei wurde "läuft" leider sehr technisch ausgelegt; das verwendete "Test-Skript" (cgi1.py) importiert ja nicht einmal CGI. THTTPD soll wegen der Authentifizierung vorgeschaltet werden. Naja, mit der Geschwindigkeit werden wir uns erstmal abfinden, so oft konfiguriert man das Gerät dann ja auch nicht.

.insert werde ich versuchen; ich fage mich trotzdem, wo ich die grundsätzlich gewählten Pfade beeinflussen kann (python24.zip gibt es z.B. nicht). sys.path =['.....', '...'], also ein komplettes Ersetzen bringt auch nicht so viel, das Suchen an sich kostet wohl nicht so viel Zeit, eher das Lesen und interpretieren.
Ein wenig ärgerlich ist das mit den falschen Pfaden ja auch dadurch, daß so immer ein 'import site failed' kommt. Gut, sieht man beim Webserver nicht, sondern nur über die Konsole, allerdings wird dies sicherlich auch beim Aufruf via CGI passieren - und möglicherweise auch Zeit kosten?

Das Foxboard ist ganz witzig, ich werde wohl privat auch mal damit spielen. Es hat zwei USB-Ports, über die man Sticks ganz normal mounten kann. Wäre sonst auch ein wenig problematisch, OS, Python, Anwendungsdaten etc. auf den acht MiB internem Speicher unterzubringen . Festplatte wäre ja auch eine Idee... da kenne ich jetzt die Technik nicht so genau, also ob IDE vorhanden ist, aber über USB als Massenspeichergerät müßte das ja dann eigentlich genauso gehen. Immerhin läuft ein komplettes Linux und nicht nur ein µ-Linux darauf.

Bis denn

[Leonidas]

Älteres und damit kleineres Python vielleicht?

Du meinst wohl ein älteres und damit langsamereres Python?

Die Werte von ``PYTHONPATH`` und ``PYTHONHOME`` werden nur übernommen, wenn sie gesetzt sind. Bist du sicher das sie das sind? Schau mal in ``os.environ``.

Das die Aufgerufene Datei nicht kompiliert wird, liegt eben genau daran, dass die Datei die aufgerufen wird eben nicht kompiliert wird. Oder, genauer - das die kompilierte Datei nicht in einer ``.pyc``-Datei gespeichert wird.

[Inmare]

Älteres und damit kleineres Python vielleicht?

Du meinst wohl ein älteres und damit langsamereres Python?

*g* Ok, dann eben nicht. Der Gedanke war einfach, daß das Laden / Importieren der Bibliothek die meiste Zeit frißt. Die Ausführungsgeschwindigkeit ist nicht der störende Faktor. Insofern könnte eine Pythonvariante mit einer kleineren Bibliothek positiv wirken. Zumal ich keine besondere Funktionalität nutze, bin eh low-levelig auf CGI, Pickle für die Serialisierung, das war es schon. Naja, string für ein paar Templates, aber die operiere ich gerade wieder raus.

Die Werte von ``PYTHONPATH`` und ``PYTHONHOME`` werden nur übernommen, wenn sie gesetzt sind. Bist du sicher das sie das sind? Schau mal in ``os.environ``.

Tja, eben dort ist das Problem. Im OS sind sie gesetzt, beim Aufruf über die Konsole klappt auch alles. Nur der Aufruf als CGI über THTTPD macht hier Probleme, dabei werden keine Enviroment-Variablen übergeben. Da ich da nicht viel dran drehen kann, hoffte ich auf einen Umweg wie beispielsweise eine an einem bestimmten Ort liegende Konfigurationsdatei, aus der der die Pfade entnommen werden.

Das die Aufgerufene Datei nicht kompiliert wird, liegt eben genau daran, dass die Datei die aufgerufen wird eben nicht kompiliert wird. Oder, genauer - das die kompilierte Datei nicht in einer ``.pyc``-Datei gespeichert wird.

Ok, ich bin mir zwar nicht ganz klar darüber, warum nicht, aber wenn das so ist... klar, ich fordere den Interpreter auf, genau diese .py-Datei zu nutzen. Bloß warum schaut er nicht, ob für diese schon ein aktuelles Kompilat existiert bzw. erstellt es, wenn es nicht vorhanden ist? Ist ja beim Import auch nicht viel anders.

Danke.

[BlackJack]

Ob eine `.pyc` vorhanden ist, wird überprüft, es wird nur keine automatisch erstellt. Das liegt daran, dass man bei Skripten normalerweise nicht erwartet, dass sie an dem Ort wo sie gestartet werden, einfach so eine Datei erzeugen.

Zu den Umgebungsvariablen: Die müssen für den Webserver bzw. den Benutzer unter dem der läuft, gesetzt werden.

[Inmare]

Hej,

Ob eine `.pyc` vorhanden ist, wird überprüft, es wird nur keine automatisch erstellt. Das liegt daran, dass man bei Skripten normalerweise nicht erwartet, dass sie an dem Ort wo sie gestartet werden, einfach so eine Datei erzeugen.

Stimmt. Zumal wenn sie im freigegebenen Ordner des Webservers liegen... ne, muß nicht.

Zu den Umgebungsvariablen: Die müssen für den Webserver bzw. den Benutzer unter dem der läuft, gesetzt werden.

Hm, da ist was dran. Stimmt, der Server läuft als "nobody". Muß ich morgen mal mit dem Admin schnacken.

Bis denn

[nkoehring]

Dieses "Foxboard" sieht ja nicht schlecht aus. Kann man an dieses Foxboard auch eine Flash-Card (z.B. mit 1GB) als Speichermedium statt einer Festplatte anschließen? Kann man eine kleine Festplatte anschließen?

Oha... das Foxboard hat mich soeben auch sabbrig gemacht
Zu deinen Fragen: Die Website zeigt sehr deutlich, dass man alles mit "Ja" beantworten kann.


Hier glaube ich, ist das Bild Erklaerung genug (http://www.acmesystems.it/?id=42)



zeigt deutlich, dass IDE-Platten anschließbar sind



Eine Frage... Die Erweiterungskarte im oberen Bild hat einen XBee-Platz. Zu XBee fand ich mit ein paar Umwegen die WikipediaSeite zu ZigBee, das ein Funknetz-Protokoll darstellt. Ist das mit WLAN kompatibel, weiß das jemand (es klingt ja so, aber mit Funk-Protokollen, also auch WLAN bin ich so gut wie garnicht vertraut...)?

Und um den Thread nicht zu sehr vom Thema Python abzuschwenken: War es schwer, Python auf das Geraet zu bekommen? Denn genau dafuer soll es am Ende sein: ein Python-basiertes "Alles"

So, ich bestell mir jetzt das Geraet *freu*

EDIT: Okay, vorerst muss ich meine Aussage revidieren...
Ich bin nun nur ein ahnungsloser Student. Vorallem Ahnungslos, wenn es um Steuernummern geht. Wenn ich das FoxBoard bestellen will, soll ich eine VAT-Nummer angeben. Hat man sowas als Normalersterblicher ohne Gewerbe? Ohne VAT-Nummer muesste ich 46Eu Mehrwertsteuer bezahlen!
Außerdem sind die Versandkosten immes (26Eu), da es von Italien geliefert wuerde... wobei ich mich damit noch abfinden koennte.

Gibt es einen deutschen "normalen" Haendler, der FoxBoards, Netzteil und die Erweiterungskarte FOXZB anbietet? Ich habe bisher keinen finden koennen

EDIT2: Ich bin nur am revidieren heute... es gibt deutsche Verkaeufer. Habe eben durch bloßen Zufall eine "Local Resellers"-Seite entdeckt

EDIT3: keine Ahnung, wie lang ich jetzt schon daran sitze... schaetzungsweise sind es drei Stunden. Fakt ist aber, dass ich bisher immernoch kein Foxboard bestellen konnte. Die deutschen Seiten sind entweder Tod oder fuer Normalkunden nicht zu gebrauchen. Am naehesten gekommen bin ich ueber SK-Pang aus UK. Aber dort koennte ich nur mit Kreditkarte bezahlen.
Ich glaube, ich muss wirklich die 20% Mehrwertsteuer und 26Eu Versandkosten bezahlen, wenn ich das Foxboard will... oder hat noch irgendwer eine Idee, wo ich das normal per Ueberweisung bezahlbar innerhalb Deutschlands kaufen kann?

Ich glaube, ein Foxboard-Heulthread ist jetzt genau das Richtige fuer mich ^^

[Inmare]

Hej,

Und um den Thread nicht zu sehr vom Thema Python abzuschwenken: War es schwer, Python auf das Geraet zu bekommen? Denn genau dafuer soll es am Ende sein: ein Python-basiertes "Alles"

für die meisten Deiner Fragen hast Du ja schon Antworten bzw. einen eigenen Thread.

Glücklicherweise mußte ich mich um die Portierung nicht kümmern.

Leider mußte ich mich um die Portierung nicht kümmern.

Glücklicherweise, weil ich mich mit dem Bauen von Python noch nicht so intensiv auseinandergesetzt habe. Bin da eher der Anwender. Dazu die doch eher ungewohnte Umgebung des Boards und seiner Werkzeuge... der Teufel steckt ja immer im Detail.

Leider, weil ich dadurch einige Zeit in der Luft hing und davon ausging, daß Python und CGI wie versprochen problemlos laufen. Tja, technisch gesehen tun sie das ja auch. Als Interpreter alleine läuft es auch problemlos. Vielleicht läuft es besser, wenn man Python als Webserver nutzt, hier sind ja schon entsprechende Lösungen vorgeschlagen worden.

Das Bauen scheint unproblematisch zu sein, wenn man das SDK für das Foxboard nutzt. Immerhin hat man dann ja ein vollwertiges Linux dahinter, also nichts beschnittenes, für das man noch Abstriche machen müsste.

[jens]

Als ersten Schritt um die Ausführungsgeschwindigkeit etwas zu erhöhen, wäre "optimize" zu nutzten.

Ersetzte dazu den Header wie z.B.:

Code: Alles auswählen

#!/usr/bin/env python

durch

Code: Alles auswählen

#!/usr/bin/env python -OO

siehe auch: http://www.python-forum.de/topic-7472.h ... t=optimize

Wie viel das wirklich bringt, weiß ich nicht. Sag mal bescheid ob du einen Unterschied feststellen kannst.

Ansonsten geht kein Weg dran vorbei von CGI weg zu kommen.

[Inmare]

Als ersten Schritt um die Ausführungsgeschwindigkeit etwas zu erhöhen, wäre "optimize" zu nutzten.

Ersetzte dazu den Header wie z.B.:

Code: Alles auswählen

#!/usr/bin/env python

durch

Code: Alles auswählen

#!/usr/bin/env python -OO

siehe auch: http://www.python-forum.de/topic-7472.h ... t=optimize

Wie viel das wirklich bringt, weiß ich nicht. Sag mal bescheid ob du einen Unterschied feststellen kannst.

Gefühlt bringt das schon ein paar Sekunden, danke für den Tip.

Ansonsten geht kein Weg dran vorbei von CGI weg zu kommen.

Tja... oder die Lösungen nutzen, die für die Hardware vorhanden und erprobt sind, auch wenn das in diesem Fall auf eine böse Sprache hinausläuft (ich nenne mal den Namen nicht, aber die Foxboardseite ist da ja doch deutlich...). Aber im Bereich des Programmierens von Embedded Devices ist man halt nicht immer frei. Und, wie schon gesagt, an der Wahl der Umgebung war ich nicht beteiligt.

[Inmare]

Als ersten Schritt um die Ausführungsgeschwindigkeit etwas zu erhöhen, wäre "optimize" zu nutzten.

Ersetzte dazu den Header wie z.B.:

Code: Alles auswählen

#!/usr/bin/env python

durch

Code: Alles auswählen

#!/usr/bin/env python -OO

Ab vom eigentlichen Thema: Du rufst Python via env auf... das kann ich mangels übergebener Umgebungsvariablen (s.o.) ja leider nicht tun. Auch ein Starten des Webservers als entsprechender Nutzer, für den die Umgebungsvariablen gesetzt sind, hilft nicht. Eigentlich stellt sich mir immer noch die Frage, woher Python sich die Modulpfade holt, wenn kein PYTHONPATH gelesen werden kann. Und vor allem, wie ich diesen anders beeinflussen kann. Eine Kommandozeilenoption dafür gibt es ja leider nicht, nur eine zum Ignorieren der gesetzten Variable.

[jens]

Wie sieht denn dein Header aus?

Du kannst natürlich auch den direkten Pfad nutzten, wie z.B.:

Code: Alles auswählen

#!/usr/bin/python --OO

[Inmare]

Wie sieht denn dein Header aus?

Du kannst natürlich auch den direkten Pfad nutzten, wie z.B.:

Code: Alles auswählen

#!/usr/bin/python --OO

Hej,
Klar, das mache ich im Augenblick auch.

[birkenfeld]

Ersetzte dazu den Header wie z.B.:

Code: Alles auswählen

#!/usr/bin/env python

durch

Code: Alles auswählen

#!/usr/bin/env python -OO

Das funktioniert so nicht; im Shebang ist genau ein Argument erlaubt.

[nkoehring]

Kannst du nicht das jeweilige setzen der Umgebungsvariablen beim Start des Systems setzen?

Tut mir leid, ich bin zu muede um das jetzt auszuschluesseln und da ich nicht weiß wie genau das Linux-System auf einem Foxboard aussieht, moechte ich mich auch nicht ans Raten wagen.

[gerold]

'import site failed'

Hallo Inmare!

"site.py" ist fixer Bestandteil von Python. Dieses Modul wird bei jedem Aufruf von Python automatisch importiert. Es ist für die Säuberung und Erweiterung des Pythonpfades und noch so einigen Dingen zuständig.

Ich mutmaße: Wenn "site.py" nicht importiert werden kann, dann hat das, speziell für Foxboard kompilierte, Python ein Problem. Vielleicht muss man vor dem Kompilieren von Python doch noch irgend einen Pfad richtig setzen. "cgi.py" liegt im gleichen Ordner wie "site.py".

Info: http://docs.python.org/lib/module-site.html

Wie stehts mit den Schreibrechten für diese Python-Ordner aus? Sind alle *.pyc- und *.pyo-Dateien für die Module erstellt? Wenn nicht -- und wenn das Schreibrecht für diese Ordner fehlt, dann könnte es eventuell Probleme geben.

Vielleicht hilft ein allgemeines Kompilieren aller Module des Python-Ordners. --> http://docs.python.org/lib/module-compileall.html

Da fällt mir noch ein: "site.py" bereinigt den Python-Pfad. Es schmeißt also alle überflüssigen Ordner, Zip-File-Pfade usw. aus dem Pfad raus. Ich kann mir schon vorstellen, dass es viel Zeit braucht, die falschen Ordner zu durchsuchen und -- jetzt kommt's -- nicht vorhandene Zip-Files zu öffnen. Auch wenn es in Python üblich ist, auf Fehler zu reagieren. Eine Exeption abzufangen braucht viel mehr Zeit als einmal vorher zu prüfen ob eine Datei existiert oder nicht.

Versuche doch mal in deinem Programm zuallererst das Modul "site" zu importieren. Vielleicht werden die darauf folgenden Module dadurch schneller importiert. Rein theoretisch sollte nach dem Importieren von "site" der Python-Pfad bereinigt sein. Falls sich "site" nicht importieren lässt, dann kopiere dieses Modul in deinen Anwendungsordner. Und wenn es dann immer noch nicht funktioniert, dann füge den Pfad zum Ordner an den Anfang des Pythonpfades hinzu. (Vielleicht ist es besser, den Eintrag "" an erster Stelle zu lassen. Füge den Pfad besser mit ``sys.path.insert(1, "pfad")`` hinzu.)

Mich würde echt interessieren, ob das etwas bringt.

Mehr fällt mir im Moment nicht ein.

mfg
Gerold

[jens]

Nur so eine Idee: Vielleicht würde es was bringen, eine eigene "site.py" Datei zu machen. Diese prüft nicht die Ordner, sondern dort werden einfach die Ordner fest vorgegeben. Das müsste um einiges schneller gehen, ist allerdings auch unflexibler...

[Inmare]

Danke für die Hilfebemühungen, ich weiß das wirklich zu schätzen.

Mittelfristig wird es wwohl eine Lösung wie CherryPy werden müssen, vielleicht auch ein Rich Client (was ja auch Java-Applet, Flash, AJAX bedeuten könnte; die Auslieferung statischer Inhalte ist ja unproblematisch).

Ersetzte dazu den Header wie z.B.:

Code: Alles auswählen

#!/usr/bin/env python

durch

Code: Alles auswählen

#!/usr/bin/env python -OO

Das funktioniert so nicht; im Shebang ist genau ein Argument erlaubt.

Hm, ich rufe ja den Interpreter direkt auf, da hat das -OO als einziges Argument dann doch seine Wirkung? Ansonsten geht nichts über einen schönen Placeboeffekt.

Kannst du nicht das jeweilige setzen der Umgebungsvariablen beim Start des Systems setzen?

Werden sie ja, sie kommen nur nicht an, auch wenn alles als root läuft. Vielleicht eine thttpd-Eigenart? Ist ja auch nicht mehr das am besten gepflegte Stück Software...

Ich mutmaße: Wenn "site.py" nicht importiert werden kann, dann hat das, speziell für Foxboard kompilierte, Python ein Problem. Vielleicht muss man vor dem Kompilieren von Python doch noch irgend einen Pfad richtig setzen. "cgi.py" liegt im gleichen Ordner wie "site.py".

cgi (und die Importe aller anderen Bibliotheken) werden ja auch nur gefunden, wenn ich den Pfad explizit setze. site.py wird ja wohl direkt beim Interpreterstart aufgerufen, bevor ich die Pfade beeinflussen kann. Na ja, werde ich mal ein site.py in das Web-Verzeichnis legen.

Wie stehts mit den Schreibrechten für diese Python-Ordner aus? Sind alle *.pyc- und *.pyo-Dateien für die Module erstellt? Wenn nicht -- und wenn das Schreibrecht für diese Ordner fehlt, dann könnte es eventuell Probleme geben.

Vielleicht hilft ein allgemeines Kompilieren aller Module des Python-Ordners. --> http://docs.python.org/lib/module-compileall.html

Schreibrechte sind gegeben, die Dateien (abgesehen von den direkt aufgerufenen) werden kompiliert und auch gespeichert.

Am Rest bastele ich noch herum.

Danke.