Geschwindigkeit des Importierens optimieren, Modulpfad setze

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Inmare
User
Beiträge: 9
Registriert: Montag 9. Juli 2007, 12:41

Montag 9. Juli 2007, 13:04

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.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Montag 9. Juli 2007, 14:42

Inmare hat geschrieben: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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Inmare
User
Beiträge: 9
Registriert: Montag 9. Juli 2007, 12:41

Montag 9. Juli 2007, 15:34

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 9. Juli 2007, 16:02

Inmare hat geschrieben:Ä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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Inmare
User
Beiträge: 9
Registriert: Montag 9. Juli 2007, 12:41

Montag 9. Juli 2007, 16:25

Leonidas hat geschrieben:
Inmare hat geschrieben:Ä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

Montag 9. Juli 2007, 16:48

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
User
Beiträge: 9
Registriert: Montag 9. Juli 2007, 12:41

Montag 9. Juli 2007, 17:28

Hej,
BlackJack hat geschrieben: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
Benutzeravatar
nkoehring
User
Beiträge: 543
Registriert: Mittwoch 7. Februar 2007, 17:37
Wohnort: naehe Halle/Saale
Kontaktdaten:

Dienstag 10. Juli 2007, 04:29

gerold hat geschrieben: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.

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


Bild
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 :roll:

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 ^^
[url=http://www.python-forum.de/post-86552.html]~ Wahnsinn ist auch nur eine andere Form der Intelligenz ~[/url]
hackerkey://v4sw6CYUShw5pr7Uck3ma3/4u7LNw2/3TXGm5l6+GSOarch/i2e6+t2b9GOen7g5RAPa2XsMr2
Inmare
User
Beiträge: 9
Registriert: Montag 9. Juli 2007, 12:41

Dienstag 10. Juli 2007, 12:06

Hej,
nkoehring hat geschrieben: 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.
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Dienstag 10. Juli 2007, 14:29

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.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Inmare
User
Beiträge: 9
Registriert: Montag 9. Juli 2007, 12:41

Dienstag 10. Juli 2007, 14:44

jens hat geschrieben: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
User
Beiträge: 9
Registriert: Montag 9. Juli 2007, 12:41

Dienstag 10. Juli 2007, 15:02

jens hat geschrieben: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.
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Dienstag 10. Juli 2007, 15:04

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

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Inmare
User
Beiträge: 9
Registriert: Montag 9. Juli 2007, 12:41

Dienstag 10. Juli 2007, 15:25

jens hat geschrieben: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.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Dienstag 10. Juli 2007, 17:24

jens hat geschrieben: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.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Antworten