Vorteile von Tuple bzw Listen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
würmchen
User
Beiträge: 255
Registriert: Mittwoch 7. November 2007, 14:17

Vorteile von Tuple bzw Listen

Beitragvon würmchen » Mittwoch 26. März 2008, 17:02

Hallo,
kann jemand mir vor und nachteile nennen mit tuples oder mit listen zu arbeiten... haben tuples irgendwie einen geschwindigkeitsvorteil oder speichervorteil? weil wenn ich bedenke das sie nich änderbar sind denke ich doch das das eher ein großer nachteil ist der mir sagt sie nicht zu benutzen.

hat da jemand erfahrung
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Beitragvon Rebecca » Mittwoch 26. März 2008, 17:17

Einen Vorteil hast du ja schon selbst genannt: Geschwindigkeit und Speicherverbrauch. Ein anderer Vorteil ist, das Tupel hashable sind, also z.B. als keys fuer Dictionaries verwendet werden koennen.

Ich benutze immer Tupel, wenn ich weiss, dass ich Daten nicht veraendern moechte.
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Beitragvon birkenfeld » Mittwoch 26. März 2008, 22:57

Ich frage mich immer noch, woher das Gerücht kommt, Tupel seien "schneller" (wobei eigentlich?).

Die Unterscheidung ist ganz einfach: Tupel sind für heterogene Daten, Listen für homogene Daten.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 26. März 2008, 23:41

birkenfeld hat geschrieben:Ich frage mich immer noch, woher das Gerücht kommt, Tupel seien "schneller" (wobei eigentlich?).

Die Logik ist einfach: sie sind wie Listen nur beschränkter. Also muss es einen Grund haben. Dieser Grund wird wohl die Performance sein, der Grund schlechthin, warum etwas beschränkt ist.

(Das das so nicht sein muss zeigen Sprachen wie Haskell oder Lisp die keineswegs beschränkter sind als etwa Java aber trotzdem die JVM alt aussehen lassen)

Dein Grund ist gut birkenfeld, so habe ich das noch nicht gesehen :)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
schorsch
User
Beiträge: 18
Registriert: Montag 26. November 2007, 18:39

Beitragvon schorsch » Mittwoch 26. März 2008, 23:58

hm hab mich auch gefragt wobei tupel schneller sein sollen. zumindest beim zugriff sind sie langsamer, wenn ich das richtig sehe.

Code: Alles auswählen

>>> setup1 = "a = [1, 2, 3]"
>>> setup2 = "a = (1, 2, 3)"
>>> expr = "b, c, d = a[0], a[1], a[2]"
>>> Timer(expr, setup1).timeit()
0.37822656231448409
>>> Timer(expr, setup2).timeit()
0.51417372878396517

beim speicherverbrauch wird es wohl anders aussehen, da tupel keine dynamischen veränderung unterstützen müssen.

ich persönlich benutze tupel eigentlich nur wenn ich einen zusammengesetzten datentyp brauche, bei dem sich eine klasse allerdings nicht lohnt. was mir da spontan einfällt wären z.b. bildschirmkoordinaten, rückgabewerte und das argument des %-stringoperators.
das tupel auch als schlüssel verwendet werden können hab ich bisher noch nciht gewusst, danke Rebecca
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Beitragvon birkenfeld » Donnerstag 27. März 2008, 09:33

schorsch hat geschrieben:hm hab mich auch gefragt wobei tupel schneller sein sollen. zumindest beim zugriff sind sie langsamer, wenn ich das richtig sehe.

Code: Alles auswählen

>>> setup1 = "a = [1, 2, 3]"
>>> setup2 = "a = (1, 2, 3)"
>>> expr = "b, c, d = a[0], a[1], a[2]"
>>> Timer(expr, setup1).timeit()
0.37822656231448409
>>> Timer(expr, setup2).timeit()
0.51417372878396517

Richtig - der Zugriff auf Listen mit Integer-Keys ist im Interpreter optimiert.
beim speicherverbrauch wird es wohl anders aussehen, da tupel keine dynamischen veränderung unterstützen müssen.

Richtig. Eine Liste alloziert mehr Speicher, als für die Pointer auf ihre aktuellen Elemente nötig ist, um nicht bei jedem append() reallozieren zu müssen.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Beitragvon CM » Donnerstag 27. März 2008, 10:30

birkenfeld hat geschrieben:Die Unterscheidung ist ganz einfach: Tupel sind für heterogene Daten, Listen für homogene Daten.


Und bei heterogenen Daten ist tuple unpacking auch in der Regel einen Tick schneller als "list unpacking". (Gerade getestet, bevor ich hier Murks behaupte.) Insofern ist Rebeccas Verwendungsfall auch meiner.

Gruß,
Christian
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Donnerstag 27. März 2008, 11:08

CM hat geschrieben:Und bei heterogenen Daten ist tuple unpacking auch in der Regel einen Tick schneller als "list unpacking". (Gerade getestet, bevor ich hier Murks behaupte.) Insofern ist Rebeccas Verwendungsfall auch meiner.

Das liegt daran, dass Tuples unter einer gewissen größe deim DECREF/gc collect nicht weggelöscht werden sondern alloziert bleiben um beim nächsten mal nicht allozieren zu müssen (aber es bleibt nur eines pro Größeneinheit "am Leben"). Das ist nützlich, wenn man "for key, value in dict.items()" macht.
TUFKAB – the user formerly known as blackbird

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder