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
Vorteile von Tuple bzw Listen
- Rebecca
- User
- Beiträge: 1662
- Registriert: Freitag 3. Februar 2006, 12:28
- Wohnort: DN, Heimat: HB
- Kontaktdaten:
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.
Ich benutze immer Tupel, wenn ich weiss, dass ich Daten nicht veraendern moechte.
Offizielles Python-Tutorial (Deutsche Version)
Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
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.
Die Unterscheidung ist ganz einfach: Tupel sind für heterogene Daten, Listen für homogene Daten.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.birkenfeld hat geschrieben:Ich frage mich immer noch, woher das Gerücht kommt, Tupel seien "schneller" (wobei eigentlich?).
(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 (former) Modvoice
hm hab mich auch gefragt wobei tupel schneller sein sollen. zumindest beim zugriff sind sie langsamer, wenn ich das richtig sehe.
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
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
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
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Richtig - der Zugriff auf Listen mit Integer-Keys ist im Interpreter optimiert.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. 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.beim speicherverbrauch wird es wohl anders aussehen, da tupel keine dynamischen veränderung unterstützen müssen.
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.birkenfeld hat geschrieben:Die Unterscheidung ist ganz einfach: Tupel sind für heterogene Daten, Listen für homogene Daten.
Gruß,
Christian
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
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.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.
TUFKAB – the user formerly known as blackbird