Performance Frage: 2d Liste vs. 1d Objekt Liste

[LiLaLaunebär]

Hi,
ich schon wieder.
Mal eine Frage zur Performance von Python:

Stellen wir uns eine Maschine vor, die 1 Teil A,1 Teil B und 1 Teil C braucht um 1 Teil X zu produzieren.
Wie speichere ich das performancetechnsich besser ab:

Code: Alles auswählen

input = [[teilA,1][teilB,1],[teilC]]
for x,y in input:
print x
#...dosth...

oder ist es so günstiger:

Code: Alles auswählen

class Input:
def _init__(self,x,y)
self.Teil=x
self.Menge=y

input=[Input(teilA,1),Input(teilB,2),Input(teilC,3)]
for x in input:
print x.Teil
#...dosth...

Was ist da in Hinblick auf Perfomance die bessere Lösung, falls denn eine besser ist..?

Danke und Gruß

[EyDu]

Hallo.

Das kommt natürlich darauf an, wie du die Daten verwendest. Wie viele Einträge willst du überhaupt speichern?

Sebastian

[BlackJack]

@LiLaLaunebär: Ich würde hier sagen das die Leistung hier egal sein sollte solange man nicht definitiv ein Problem damit hat. Und zwar ein belegbares, nicht ein vermutetes. Das ist eine "Mikrooptimierung" bei der man sich IMHO immer ersteinmal für die lesbarere und wartbarere Variante entscheiden sollte.

[LiLaLaunebär]

es werden nicht viele einträge sein. denke so 5 pro liste. allerdings wird es viele listen geben...so an die 100.
und auf die wird häufig zugegriffen...sagen wir 5000 mal pro liste während der gesamten laufzeit der simulation. diese sollte allerdings in möglichst kurzer zeit ausgeführt werden, da es sich letztendlich um ein decision support system handeln soll (aber ob es das auch wird??? ).
weiß nicht ob man das noch als klein oder schon als groß einordnet, hab da 0 erfahrung
hab davon leider keine ahnung, also was so performance fragen betrifft. aber wenn man hier was suboptimal wählt und dort...
ich kann es leider auch noch nicht testen, weil das tool noch nicht fertig ist, aber ich muss mich nun entscheiden.

[BlackJack]

@LiLaLaunebär: Wie gesagt -- IMHO kein Grund sich die Frage zu stellen. In diesem Stadium kann man entscheiden welche Komplexität die Algorithmen haben sollten, aber nicht solche Kleinigkeiten. Solange diese letztendlich konstanten Unterschiede kein nachweisliches Problem darstellen, sollte man sich damit auch nicht aufhalten.

Wenn die Anwendung steht, kann man immer noch den Profiler anwerfen und schauen wo *tatsächlich* die meiste Zeit verbraten wird, und dort dann *gezielt* ansetzen, als sich jetzt schon bei solchen Kleinigkeiten einen Kopf zu machen, wo man noch nicht einmal sicher ist, ob das am Ende im Gesamtsystem überhaupt merkliche Verbesserungen bringt.

[jbs]

5000 sind nicht viel. Also quasi nix. Hast du mal Performancetests gemacht?


Edit: Also Tests um einfach mal ein Gefühl zu bekommen, wie schnell der Computer doch ist..

[LiLaLaunebär]

nein, habe ich noch nicht, weil das ganze ein skalierbares simulationsmodell wird.also das kann man dann beliebig groß machen...und wie groß es dann letztendlich sein wird weiß noch keiner...deshalb kann ich noch keinen performancetest machen.
aber ok, wenn 5000 nicht viel sind, dann wirds schon passen...
danke!

[numerix]

Solche Fragen kann man sich leicht selbst beantworten. Erzeuge dir einfach einen Haufen Daten und vergleiche die Laufzeit der beiden Variante. Dabei dürftest du feststellen, dass die Tupel-Variante eindeutig performanter ist als die Klassen-Variante. Wenn du tatsächlich nicht mehr Informationen brauchst, als die Teile-ID und die Anzahl, dann gibt es IMHO - abgesehen von der Performance - auch im Hinblick auf das Design keinen Grund, hier eine Klasse einzusetzen. Ggf. könntest du noch namedtuple einsetzen. Wie performant die sind, habe ich allerdings noch nicht ausprobiert.

[noisefloor]

Hallo,

solange du nicht viel mit den Listen "hantierst" (z.B. Elemente vorne einfügen, Elemente löschen), sollte das IMHO egal sein.

IMHO ist ein einfachere Alternative als eine eigene Klasse aber ein Dict. Z.B.:

Code: Alles auswählen

input1 = {"teil1":1, "teil2":1,"teil3":1}
input2 = {...}

Ob das aber schneller oder langsamer ist als eine Liste von Listen -> musst du Messen

Gruß, noisefloor