Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.

...powered by haas.homelinux.net...

Inhaltsverzeichnis
1 Einleitung
2 Überblick über Python
3 Die Arbeit mit Python
4 Der interaktive Modus
5 Grundlegendes zu Python-Programmen
6 Kontrollstrukturen
7 Das Laufzeitmodell
8 Basisdatentypen
9 Benutzerinteraktion und Dateizugriff
10 Funktionen
11 Modularisierung
12 Objektorientierung
13 Weitere Spracheigenschaften
14 Mathematik
15 Strings
16 Datum und Zeit
17 Schnittstelle zum Betriebssystem
18 Parallele Programmierung
19 Datenspeicherung
20 Netzwerkkommunikation
21 Debugging
22 Distribution von Python-Projekten
23 Optimierung
24 Grafische Benutzeroberflächen
25 Python als serverseitige Programmiersprache im WWW mit Django
26 Anbindung an andere Programmiersprachen
27 Insiderwissen
28 Zukunft von Python
A Anhang
Stichwort

Download:
- ZIP, ca. 4,8 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Python von Peter Kaiser, Johannes Ernesti
Das umfassende Handbuch - Aktuell zu Python 2.5
Buch: Python

Python
gebunden, mit CD
819 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1110-9
Pfeil 21 Debugging
  Pfeil 21.1 Der Debugger
  Pfeil 21.2 Inspizieren von Instanzen – inspect
    Pfeil 21.2.1 Datentypen, Attribute und Methoden
    Pfeil 21.2.2 Quellcode
    Pfeil 21.2.3 Klassen und Funktionen
  Pfeil 21.3 Formatierte Ausgabe von Instanzen – pprint
  Pfeil 21.4 Logdateien – logging
    Pfeil 21.4.1 Das Meldungsformat anpassen
    Pfeil 21.4.2 Logging Handler
  Pfeil 21.5 Automatisiertes Testen
    Pfeil 21.5.1 Testfälle in Docstrings – doctest
    Pfeil 21.5.2 Unit Tests – unittest
  Pfeil 21.6 Traceback-Objekte – traceback
  Pfeil 21.7 Analyse des Laufzeitverhaltens
    Pfeil 21.7.1 Laufzeitmessung – timeit
    Pfeil 21.7.2 Profiling – cProfile
    Pfeil 21.7.3 Tracing – trace


Galileo Computing - Zum Seitenanfang

21.7 Analyse des Laufzeitverhaltens  Zur nächsten ÜberschriftZur vorigen Überschrift

Die Optimierung eines Programms ist ein wichtiger Teilbereich der Programmierung und kann viel Zeit in Anspruch nehmen. In der Regel wird zunächst ein lauffähiges Programm erstellt, das alle gewünschten Anforderungen erfüllt, bei dem jedoch noch nicht unbedingt Wert auf die Optimierung der Algorithmik gelegt wird. Das liegt vor allem daran, dass man oftmals erst beim fertigen Programm die tatsächlichen Engpässe erkennt und im frühen Stadium somit eventuell viel Zeit in die Optimierung völlig unkritischer Bereiche investieren würde.

Um das Laufzeitverhalten eines Python-Programms möglichst genau zu erfassen, existieren die drei Module timeit, profile und cProfile in der Standardbibliothek von Python. Diese Module sollen das Thema der nächsten Abschnitt sein.


Galileo Computing - Zum Seitenanfang

21.7.1 Laufzeitmessung – timeit  Zur nächsten ÜberschriftZur vorigen Überschrift

Das Modul timeit der Standardbibliothek ermöglicht es, genau zu messen, wie lange ein Python-Programm zur Ausführung braucht. Üblicherweise wird timeit dazu verwendet, die Laufzeit zweier verschiedener Algorithmen für dasselbe Problem zu vergleichen.

Sie erinnern sich sicherlich noch, dass im Kapitel über Funktionen zwei Algorithmen zur Berechnung der Fakultät einer ganzen Zahl besprochen wurden: ein iterativer und ein rekursiver. Es wurde gesagt, dass ein laufzeitoptimierter iterativer Algorithmus im Vergleich zu seinem rekursiven Pendant stets effizienter ist. Das wollen wir in diesem Kapitel anhand des timeit-Moduls überprüfen, und zusätzlich wollen wir testen, um wie viel Prozent schneller die iterative Variante tatsächlich ausgeführt werden kann.

Um die Laufzeit eines Python-Codes zu testen, muss die im Modul timeit enthaltene Klasse Timer instanziiert werden. Der Konstruktor der Klasse Timer hat folgende Schnittstelle:

timeit.Timer([stmt[, setup[, timer]]])

Erzeugt eine Instanz der Klasse Timer. Der zu analysierende Python-Code kann dem Konstruktor in Form des Parameters stmt als String übergeben werden. Für den zweiten Parameter setup kann ebenfalls ein String übergeben werden, der den Python-Code enthält, der zur Initialisierung von stmt benötigt wird. Demzufolge wird setup auch vor stmt ausgeführt. Beide Parameter sind optional und mit dem String "pass" vorbelegt.

Als dritter optionaler Parameter timer kann eine Zeitgeberfunktion übergeben werden. Dies sollte eine der Funktionen time.time oder time.clock des Moduls time sein. Standardmäßig wird diejenige dieser beiden Funktionen verwendet, die auf dem aktuellen System die höchste Auflösung bietet. Das ist time.time unter Windows und time.clock unter Unix-artigen Betriebssystemen. Es ist normalerweise nicht notwendig, diesen Parameter anzugeben.

Die Klasse Timer

Nachdem eine Instanz der Klasse Timer erzeugt worden ist, besitzt sie drei Methoden, die im Folgenden besprochen werden sollen. Dabei sei t eine Instanz der Klasse Timer.

t.timeit([number])

Diese Methode führt zunächst den setup-Code einmalig aus und wiederholt danach den beim Konstruktor für stmt übergebenen Code number-mal. Wenn der optionale Parameter number nicht angegeben wurde, wird der zu messende Code 1.000.000-mal ausgeführt.

Die Funktion gibt die Zeit zurück, die das Ausführen des gesamten Codes (also inklusive aller Wiederholungen, jedoch exklusive des Setup-Codes) in Anspruch genommen hat. Der Wert wird in Sekunden als Gleitkommazahl zurückgegeben.


Hinweis
Um das Ergebnis von äußeren Faktoren so unabhängig wie möglich zu machen, wird für die Dauer der Messung die Garbage Collection des Python-Interpreters deaktiviert. Sollte die Garbage Collection ein wichtiger mitzumessender Teil Ihres Codes sein, so lässt sie sich mit einem Setup-Code von "gc.enable()" wieder aktivieren.


t.repeat([repeat[, number]])

Ruft die Methode timeit repeat-mal auf und gibt die Ergebnisse in Form einer Liste von Gleitkommazahlen zurück. Der Parameter number wird dabei der Methode timeit bei jedem Aufruf übergeben.


Hinweis
Es ist normalerweise keine gute Idee, den Mittelwert aller von repeat zurückgegebenen Werte zu bilden und diesen als durchschnittliche Laufzeit auszugeben. Andere Prozesse, die auf Ihrem System laufen, verfälschen die Ergebnisse aller Messungen. Vielmehr sollten Sie den kleinsten Wert der zurückgegebenen Liste als minimale Laufzeit annehmen, da dies die Messung mit der geringsten Systemaktivität war.


t.print_exc([file])

Sollte im zu analysierenden Code eine Exception geworfen werden, wird die Analyse sofort abgebrochen und ein Traceback ausgegeben. Der Stacktrace dieses Tracebacks ist jedoch nicht immer optimal, da er sich nicht auf den tatsächlich ausgeführten Quellcode bezieht.

Um einen aussagekräftigeren Stacktrace auszugeben, kann eine geworfene Exception abgefangen und die Methode print_exc aufgerufen werden. Diese Methode gibt einen Traceback auf dem Bildschirm aus, der sich direkt auf den zu analysierenden Code bezieht und damit die Fehlersuche erleichtert.

Durch Angabe des optionalen Parameters file lässt sich die Ausgabe in eine beliebige Datei umleiten.

Beispiel

Eingangs wurde erwähnt, dass wir das Modul timeit dazu verwenden werden, zu prüfen, um wie viel Prozent die iterative Fakultätsberechnung schneller ist als die rekursive.

Dazu binden wir zunächst das Modul timeit ein und implementieren die beiden Berechnungsfunktionen.

import timeit
def fak1(n): res = 1 for i in xrange(2, n+1): res *= i return res
def fak2(n): if n > 0: return fak2(n-1)*n else: return 1

Danach wird für beide Funktionen jeweils eine Instanz der Klasse Timer erzeugt:

t1 = timeit.Timer("fak1(50)", "from __main__ import fak1") 
t2 = timeit.Timer("fak2(50)", "from __main__ import fak2")

Beachten Sie, dass wir im Setup-Code zunächst die gewünschte Berechnungsfunktion aus dem Namensraum des Hauptprogramms __main__ in den Namensraum des zu testenden Programms importieren müssen. Im eigentlich zu analysierenden Code wird nur noch die Berechnung der Fakultät von 50 unter Verwendung der jeweiligen Berechnungsfunktion angestoßen.

Schlussendlich wird die Laufzeitmessung mit 1.000.000 Wiederholungen gestartet und das jeweilige Ergebnis ausgegeben:

print "Iterativ: ", t1.timeit() 
print "Rekursiv: ", t2.timeit()

Die Ausgabe des Programms lautet:

Iterativ:  16.1009089947 
Rekursiv:  28.7318170071

Das würde bedeuten, dass der iterative Algorithmus um ca. 40 % schneller ist als der rekursive. Doch diese Daten sind noch nicht wirklich repräsentativ, denn es könnte sein, dass der Test der rekursiven Funktion durch einen im System laufenden Prozess ausgebremst wurde. Aus diesem Grund starten wir einen erneuten Test:

print "Iterativ: ", min(t1.repeat(100, 10000)) 
print "Rekursiv: ", min(t2.repeat(100, 10000))

Dieses Mal führen wir eine Testreihe durch, die einen Test mit 10.000 Einzelwiederholungen 100-mal wiederholt und das kleinste der Ergebnisse ausgibt. Die Ergebnisse sind, relativ gesehen, annäherungsweise deckungsgleich mit denen der vorherigen Tests:

Iterativ:  0.162111997604 
Rekursiv:  0.272562026978

Beachten Sie, dass die absoluten Zahlenwerte sehr stark vom verwendeten System abhängen. Auf einem schnelleren Computer sind sie dementsprechend kleiner.


Galileo Computing - Zum Seitenanfang

21.7.2 Profiling – cProfile  Zur nächsten ÜberschriftZur vorigen Überschrift

Um eine Laufzeitanalyse eines vollständigen Python-Programms anzufertigen, wird ein sogenannter Profiler verwendet. Ein Profiler überwacht einen kompletten Programmdurchlauf und listet nach Beenden des Programms detailliert auf, wie viel Prozent der Laufzeit beispielsweise in welcher Funktion verbraucht wurden. Auf diese Weise kann der Programmierer die laufzeittechnischen Engpässe des Programms erkennen und an sinnvollen Stellen mit der Optimierung des Programms beginnen.

Grundsätzlich gilt: Je mehr Prozent der Laufzeit in einer bestimmten Funktion verbracht werden, desto mehr Zeit sollte man investieren, um diese Funktion zu optimieren. Dagegen wäre es Zeitverschwendung, stundenlang eine Funktion zu optimieren, die vielleicht nur einmal zur Initialisierung des Programms aufgerufen wird.

Seit Python Version 2.5 ist in der Standardbibliothek ein neuer Profiler namens cProfile enthalten. Dieser bildet die Schnittstelle des alten Profilers profile ab, ist jedoch im Gegensatz zu diesem in C statt in Python geschrieben. Aus diesem Grund ist der Overhead von cProfile kleiner, und die Zeitmessungen sind somit besser. Wir werden hier den Profiler cProfile besprechen. Da dieser jedoch über die gleiche Schnittstelle wie profile verfügt, gilt die Beschreibung genauso für den alten Profiler.

Beachten Sie, dass der Profiler cProfile möglicherweise nicht für alle Python-Interpreter verfügbar ist. Das reine Python-Pendant profile hingegen kann überall verwendet werden.

Verwendung des Moduls

Im Modul cProfile sind im Wesentlichen zwei wichtige Funktionen enthalten, die im Folgenden besprochen werden sollen.

cProfile.run(command[, filename])

Diese Funktion führt den als command übergebenen String mithilfe einer exec-Anweisung aus und führt während der Ausführung eine detaillierte Laufzeitanalyse durch. Üblicherweise wird für command ein Funktionsaufruf der Hauptfunktion eines größeren Programms übergeben.

Über den zweiten, optionalen Parameter filename kann eine Datei angegeben werden, in die das Ergebnis der Laufzeitanalyse geschrieben wird. Wenn dieser Parameter nicht angegeben wurde, wird das Ergebnis auf dem Bildschirm ausgegeben. Bei diesem Ergebnis der Analyse handelt es sich um eine tabellarische Auflistung aller Funktionsaufrufe. Wie diese Tabelle aussieht und wie sie zu lesen ist, wird im Beispiel-Teil dieses Kapitels geklärt.

cProfile.runctx(command, globals, locals[, filename])

Diese Funktion verhält sich wie run, mit dem Unterschied, dass über die Parameter globals und locals der globale und lokale Kontext festgelegt werden kann, in dem command ausgeführt wird. Für die Parameter globals und locals kann ein Dictionary übergeben werden, wie es von den Built-in Functions globals und locals zurückgegeben wird.

Beispiel

Im Folgenden soll eine Laufzeitanalyse für ein kleines Beispielprogramm erstellt werden. Dazu betrachten wir zunächst den Quelltext des Programms:

import math
def calc1(n): return n**2
def calc2(n): return math.sqrt(n)
def calc3(n): return math.log(n+1)
def programm(): for i in xrange(100): calc1(i) for j in xrange(100): calc2(j) for k in xrange(100): calc3(k)
programm()

Im Programm existieren drei kleine Funktionen namens calc1, calc2 und calc3, die jeweils eine ganze Zahl als Parameter übergeben bekommen, dann eine mathematische Operation auf dieser Zahl anwenden und das Ergebnis zurückgeben. In der Hauptfunktion programm befinden sich drei ineinander verschachtelte Schleifen, die jeweils über alle ganzen Zahlen von 0 bis 99 iterieren und eine der drei Berechnungsfunktionen aufrufen. Die Frage, die wir mithilfe des Profilers lösen möchten, lautet, an welcher Stelle sich eine Optimierung des Programms besonders lohnen würde und wo sie überflüssig wäre.

Der Profiler wird folgendermaßen in das Programm eingebunden:

import cProfile 
[…] 
cProfile.run("programm()")

wobei die Auslassungszeichen für den Code des Beispielprogramms stehen. Beachten Sie, dass die Codezeile programm() des Beispielprogramms jetzt überflüssig ist. Das Ausführen der Laufzeitanalyse gibt folgendes Ergebnis aus:

      2020103 function calls in 6.115 CPU seconds 
 
Ordered by: standard name 
 
ncalls  tottime percall cumtime percall filename:lineno(function) 
      1 0.000   0.000   6.115   6.115   <string>:1(<module>) 
1000000 2.916   0.000   4.467   0.000   programm.py:10(calc3) 
      1 1.603   1.603   6.115   6.115   programm.py:13(programm) 
    100 0.000   0.000   0.000   0.000   programm.py:4(calc1) 
  10000 0.030   0.000   0.045   0.000   programm.py:7(calc2) 
1000000 1.551   0.000   1.551   0.000   {math.log} 
  10000 0.015   0.000   0.015   0.000   {math.sqrt} 
      1 0.000   0.000   0.000   0.000   {method 'disable' of 
                                      '_lsprof.Profiler' objects}

Jede Zeile dieser Tabelle bezieht sich auf eine Funktion des Beispielprogramms. Die Spaltenbeschriftungen der Tabelle sind vielleicht nicht ganz klar, weswegen sie kurz erläutert werden sollen:

  • ncalls steht für die Anzahl von Funktionsaufrufen der Funktion.
  • tottime steht für die Gesamtzeit in Sekunden, die in der Funktion verbracht wurde. Dabei werden Aufrufe von Unterfunktionen nicht einbezogen.
  • percall steht für den Quotienten von tottime und ncalls.
  • cumtime steht für die Gesamtzeit in Sekunden, die in der Funktion verbracht wurde. Dabei werden Aufrufe von Unterfunktionen mit einbezogen.
  • percall steht für den Quotienten von cumtime und ncalls.
  • filename:lineno(function) steht für den Funktionsnamen, inklusive Angabe der Programmdatei und der Zeile, an der die Funktion im Quellcode steht.

Die vom Profiler angezeigte Tabelle gibt einen guten Überblick darüber, wo die zeitkritischen Funktionen des Programms liegen. In diesem Fall sticht die Funktion calc3 hervor, die insgesamt 1.000.000-mal aufgerufen wird und in der sich satte 73 % der Laufzeit abspielen. Die 10.000-mal aufgerufene Funktion calc2 macht hingegen nur 0,7 % der Gesamtlaufzeit aus. Die restliche Laufzeit wird, abgesehen von einem verschwindend geringen Prozentsatz in calc1, in der Hauptfunktion programm verbracht.

Zugegebenermaßen hätte man dieses Ergebnis auch anhand des Programms abschätzen können. Jede Schleife iteriert über 100 Zahlen und ruft in jedem Iterationsschritt »ihre« Funktion auf. Damit wird die innerste Funktion 1003 = 1.000.000-mal aufgerufen. Auch die prozentuale Laufzeit der Funktionen calc3 und calc2 liegt in etwa um Faktor 100 auseinander. Etwaige Schwankungen rühren daher, dass unterschiedliche Berechnungen durchgeführt werden (Logarithmusfunktion gegen Wurzelfunktion).

Auch wenn dieses Beispiel etwas künstlich wirkt, kann man die Vorgehensweise auf ein größeres, zeitkritisches Projekt übertragen. Im Falle unseres Beispiels wäre man gut damit beraten, alle Ressourcen in die Optimierung der Funktion calc3 zu stecken, da diese mit 1.000.000 Aufrufen und 73 % Laufzeitanteil doch stark dominiert.


Galileo Computing - Zum Seitenanfang

21.7.3 Tracing – trace  topZur vorigen Überschrift

Im letzten Abschnitt haben wir besprochen, welche Möglichkeiten Python bietet, ein Programm mithilfe eines Profilers zu untersuchen. Dies funktioniert im besprochenen Beispiel sehr gut, hat aber auch einen großen Nachteil: Der Profiler arbeitet auf der Funktionsebene. Das bedeutet, dass immer nur die Laufzeit ganzer Funktionen gemessen wird. Häufig ist es aber so, dass es auch innerhalb einer größeren Funktion Teile gibt, die laufzeittechnisch gesehen bedeutungslos sind, und welche, die sehr laufzeitintensiv sind. In einem solchen Fall greift man zu einem anderen Hilfsmittel, dem sogenannten Tracer.

Ein Tracer, in Python über das Modul trace verfügbar, überwacht einen Programmlauf und registriert dabei, wie oft jede einzelne Codezeile des Programms ausgeführt wurde. Eine solche Überdeckungsanalyse wird im Wesentlichen aus zwei Gründen durchgeführt:

  • Mithilfe einer Überdeckungsanalyse lassen sich Codezeilen ausfindig machen, die besonders häufig aufgerufen werden und daher möglicherweise besonders laufzeitintensiv sind. Diese Zeilen könnten dann gezielt optimiert werden. Beachten Sie aber, dass ein Tracer nicht die tatsächliche Laufzeit einer Codezeile misst, sondern nur, wie oft diese Zeile im Programmfluss ausgeführt wurde.
  • Häufig muss bei sicherheitsrelevanten Programmen eine Überdeckungsanalyse vorgelegt werden, um zu beweisen, dass bei einem Test jede Codezeile mindestens einmal ausgeführt wurde. Auf diese Weise versucht man zu vermeiden, dass beispielsweise der Autopilot eines Flugzeugs ausfällt, weil eine Codezeile ausgeführt wurde, an die man beim Testen der Software nicht gedacht hat.

In diesem Kapitel möchten wir die Überdeckungsanalyse durchführen, um laufzeitkritische Stellen in einem Programm zu identifizieren. Dazu erstellen wir eine leicht modifizierte Version des Beispielprogramms aus dem vorangegangenen Kapitel. »Modifiziert« bedeutet, dass der Code ohne Unterfunktionen geschrieben wurde.

import math
def programm(): for i in xrange(100): i**2 for j in xrange(100): math.sqrt(j) for k in xrange(100): math.log(k+1)

Die Überdeckungsanalyse wird mithilfe des Moduls trace durchgeführt. Dazu ist folgender zusätzlicher Code nötig:

import trace 
import sys
tracer = trace.Trace( ignoredirs = [sys.prefix, sys.exec_prefix], trace = 0) tracer.run("programm()")
r = tracer.results() r.write_results(show_missing=True, coverdir="ergebnis")

Zunächst wird eine Instanz der Klasse Tracer erzeugt. Diese bekommt zwei Schlüsselwortparameter übergeben. Über den Parameter ignoredirs wird eine Liste von Verzeichnissen übergeben, deren enthaltene Module nicht in die Überdeckungsanalyse mit einbezogen werden sollen. In diesem Fall möchten wir keine Module der Standardbibliothek übergeben und fügen deshalb die entsprechenden Verzeichnisse sys.prefix und sys.exec_prefix an. Den zweiten Parameter, trace, setzen wir auf 0, da sonst jede während des Programmlaufs ausgeführte Zeile auf dem Bildschirm ausgegeben wird.

Danach führen wir, analog zum Profiler, die Methode run der Trace-Instanz aus und übergeben dabei den auszuführenden Python-Code. Nachdem der Tracer durchgelaufen ist, können die Ergebnisse über die Methode results der Trace-Instanz abgeholt werden. Wir möchten die Ergebnisse in diesem Fall nicht weiterverarbeiten und speichern sie deshalb mithilfe der Methode write_results auf der Festplatte. Dabei wird über den Parameter coverdir das Unterverzeichnis angegeben, in dem die Ergebnisse gespeichert werden sollen. Wenn für den Parameter show_missing True übergeben wird, werden Codezeilen, die während des Programmlaufs niemals ausgeführt wurden, mit einem Pfeil gekennzeichnet.

Das Ergebnis wird im Unterordner ergebnis als Textdatei mit dem Dateinamen modulname.cover abgespeichert, wobei modulname durch den Namen Ihres getesteten Moduls ersetzt wird. In unserem Beispiel sieht das Ergebnis folgendermaßen aus:

       import trace 
>>>>>> import sys
>>>>>> import math >>>>>> def programm(): 101: for i in xrange(100): 100: i**2 10100: for j in xrange(100): 10000: math.sqrt(j) 1010000: for k in xrange(100): 1000000: math.log(k+1)
>>>>>> tracer = trace.Trace( >>>>>> ignoredirs = [sys.prefix, sys.exec_prefix], >>>>>> trace = 0) >>>>>> tracer.run("programm()")
>>>>>> r = tracer.results() >>>>>> r.write_results(show_missing=True, coverdir="ergebnis")

Sie sehen, dass die Ergebnisse zu einer gut lesbaren Datei aufbereitet werden. Im Prinzip ist die Datei in zwei Spalten aufgeteilt: Rechts steht der Quellcode des Programms und links die Anzahl der Aufrufe jeder Codezeile. Die Pfeile in der linken Spalte weisen auf Codezeilen hin, die während des überwachten Programmlaufs niemals ausgeführt wurden. Beachten Sie, dass diese Zeilen natürlich nur nicht ausgeführt wurden, solange die Überwachung des Programms aktiv war.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






 <<   zurück
  
  Zum Katalog
Zum Katalog: Python






Python
bestellen
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchtipps
Zum Katalog: Linux






 Linux


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


Zum Katalog: Praxisbuch Web 2.0






 Praxisbuch Web 2.0


Zum Katalog: UML 2.0






 UML 2.0


Zum Katalog: Praxisbuch Objektorientierung






 Praxisbuch Objektorientierung


Zum Katalog: Einstieg in SQL






 Einstieg in SQL


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für Fachinformatiker


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo