Speicherbegrenzung String

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.
BlackJack

@epsilon: Kannst Du Deinen Benchmark vielleicht noch einmal Verfügbar machen? Der Paste ist anscheinend nach der Umstellung von ubuntuusers weg.

@BastiL: Wie sieht's mit der Zeit aus, wenn Du auch wirklich die Daten extrahierst und in eine Datei schreibst?
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

Das mit der Zeit für extrahieren und Schreiben müsste ich mir ansehen. Das ist allerdings im benchmark von Epsilon auch nicht dabei, das ist auch die reine Suchzeit. Das Schreiben geht gefühlt auf jeden Fall schneller als das Suchen, die gesamte Programmlaufzeit liegt für meinen Code unter 30 Sekunden.
epsilon
User
Beiträge: 71
Registriert: Freitag 20. Juni 2008, 19:48

Über den Cache von Google ist das Skript noch verfügbar (Hier mit Formatierung)

Das Skript hatte noch einen bug, wodurch in byteweise() immer die Selbe Anzahl an Bytes eingelesen wurde. Der Unterschied ist allerdings gering (falls es überhaupt einen Unterschied gibt):

mem: 6.33056998253 Sekunden
mmap: 6.20173692703 Sekunden
104857 Byte: 6.86206698418 Sekunden
10485760 Byte: 6.63443303108 Sekunden
104857600 Byte: 6.43973302841 Sekunden
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

Irgendwie hat mir das bisher nicht so ganz weitergeholfen. Was ich im Moment v.a. nicht verstehe ist der große Performenceunterschied zwischen meinem Skript und der "mem" Variante im Benchmark von epsilon. Das Einlesen ist ja genau gleich, anscheinend liegt das im Matchen es re? Ich muss da mal ein paar Tests fahren... Habt Ihr noch Ideen?
epsilon
User
Beiträge: 71
Registriert: Freitag 20. Juni 2008, 19:48

BastiL hat geschrieben:[...] Was ich im Moment v.a. nicht verstehe ist der große Performenceunterschied zwischen meinem Skript und der "mem" Variante im Benchmark von epsilon. Das Einlesen ist ja genau gleich, anscheinend liegt das im Matchen es re? Ich muss da mal ein paar Tests fahren... Habt Ihr noch Ideen?
Das kann ich mir ehrlich gesagt auch nicht erklären. Das Einzige, was ich mir denken könnte, ist dass du nicht den selben Regulären Ausdruck verwendet hast (hast du auch die Flags ausgetauscht? Also dein 're.I' gegen mein 're.S | re.U' ? Wenn nicht, teste das mal.).

Dann frage ich mich noch, wie du in 10 Sekunden 2 GB einlesen und den RE drüber laufen lassen willst? (Ich brauche alleine für das einlesen von 1 GB 30 Sekunden, und das ist das reine einlesen. Vielleicht hast du aber auch nur 'ne besser Festplatte als ich ;))

Dann frage ich mich noch: Hast auch (wie ich) für jeden Test eine andere file verwendet, bzw. vor jedem Test den Cache gelöscht? Benen' doch mal deine Testfile um und teste mit ihr dein Testskript, nachdem du meine 'mem' Funktion verwend hast.

BastiL hat geschrieben:Irgendwie hat mir das bisher nicht so ganz weitergeholfen.
Hast du überhaupt getestet, ob man mit mmap auf einem 64-Bit System größere Dateien als 2 bis 3 GB adressieren kann? Vom speed her darf ja mmap eigentlich gar nicht langsamer sein als das direkte, komplette Einlesen in den Speicher (wenn man auf jede Stelle in der file sowieso nur einmal mit dem RE zugreift). In meinen Tests war mmap sogar ein wenig schneller als das Einlesen in den Speicher.
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

epsilon hat geschrieben: Das Einzige, was ich mir denken könnte, ist dass du nicht den selben Regulären Ausdruck verwendet hast (hast du auch die Flags ausgetauscht? Also dein 're.I' gegen mein 're.S | re.U' ? Wenn nicht, teste das mal.).
Das habe ich nicht. Mein Programm hat nach wie vor den Flag re.I, das Benchmark von Dir re.S | re.U. Das macht wohl den Unterschied und das muss ich mir jetzt ansehen.
epsilon hat geschrieben:Dann frage ich mich noch, wie du in 10 Sekunden 2 GB einlesen und den RE drüber laufen lassen willst? (Ich brauche alleine für das einlesen von 1 GB 30 Sekunden, und das ist das reine einlesen. Vielleicht hast du aber auch nur 'ne besser Festplatte als ich ;))
Um ehrlich zu sein macht das mein Rechner nicht ich ;) Ich kann nicht so schnell lesen....
Dann frage ich mich noch: Hast auch (wie ich) für jeden Test eine andere file verwendet, bzw. vor jedem Test den Cache gelöscht? Benen' doch mal deine Testfile um und teste mit ihr dein Testskript, nachdem du meine 'mem' Funktion verwend hast.
Nein ich verwende dasselbe File. Dein Pfad zeigt doch auch immer auf die gleiche Datei?? Bei meinem Benchmark habe ich lediglich den Pfad geändert - zeige aber immer auf dieselbe Datei, genau wie Du....
Hast du überhaupt getestet, ob man mit mmap auf einem 64-Bit System größere Dateien als 2 bis 3 GB adressieren kann?
Noch nicht. Das muss ich machen, dazu gibt es im Netz durchaus widersprüchliche Infos...
Vom speed her darf ja mmap eigentlich gar nicht langsamer sein als das direkte, komplette Einlesen in den Speicher (wenn man auf jede Stelle in der file sowieso nur einmal mit dem RE zugreift). In meinen Tests war mmap sogar ein wenig schneller als das Einlesen in den Speicher.
Korrekt. Daher wäre das für mich der Weg wenn das mit Files > 2GB läuft...
Ich melde mich wieder wenn ich die Tests gefahren habe.
epsilon
User
Beiträge: 71
Registriert: Freitag 20. Juni 2008, 19:48

BastiL hat geschrieben: Nein ich verwende dasselbe File. Dein Pfad zeigt doch auch immer auf die gleiche Datei?? Bei meinem Benchmark habe ich lediglich den Pfad geändert - zeige aber immer auf dieselbe Datei, genau wie Du....
Ne ich hab's immer mit 'ner anderen file getestet (siehe hier):
dewiktionary-20080617-pages-articles00.xml
dewiktionary-20080617-pages-articles01.xml
dewiktionary-20080617-pages-articles02.xml
dewiktionary-20080617-pages-articles03.xml
dewiktionary-20080617-pages-articles04.xml
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

Also: wenn ich die Flags in meinem (schnellen) Skript tausche (re.S | re.U statt re.I) dann bleibt das Tempo gleich hoch, genauso wenn ich statt meinem re.search dein re.compile verwende.... Dein Skript bleibt deutlich langsamer.... Keine Ahnung warum...

Das Problem 2GB Grenze bleibt: wenn ich mmap verwende bekomme ich:

OverflowError: memory mapped size is too large (limited by C int)

Das scheint wohl auch ein Problem der Implementierung von Python 2.4.2 zu sein, selbst wenn ich die 64 Bit Version verwende (was ich gar nicht weiss - wie finde ich das heraus?)
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Ich weiß grad nicht wie das bei Windows aussieht (müsste aber in sys.version stehen), aber eine Methode das herauszufinden ist:

Code: Alles auswählen

>>> sys.maxint == 2**(32-1)-1
False
>>> sys.maxint == 2**(64-1)-1
True
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

Leonidas hat geschrieben:Ich weiß grad nicht wie das bei Windows aussieht (müsste aber in sys.version stehen), aber eine Methode das herauszufinden ist:

Code: Alles auswählen

>>> sys.maxint == 2**(32-1)-1
False
>>> sys.maxint == 2**(64-1)-1
True
So sieht das bei mir auch aus. Ist kein Win sondern 64Bit Linux. Die Binary ist auch 64-bittig...
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

Tja ich weiss nicht mehr so richtig weiter. Meine Python-Version ist 2.4.2. Wenn man das Problem googelt dann bekommt man sehr unterschiedliches dazu... Allerdings scheint Python 2.5 damit generell weniger Probleme zu haben. Hat jemand Erfahrungen mit so großen Files?
Benutzeravatar
Trundle
User
Beiträge: 591
Registriert: Dienstag 3. Juli 2007, 16:45

Zumindest bei der x86_64-Architektur (aka amd64) gilt sizeof(int) == 4 und (C)Python hat intern sehr oft ints benutzt, etwa beim Indizieren oder eben auch bei mmap-Objekten. Mit Python 2.5 wurden diese ints dann durch einen eigenen Datentyp (Py_ssize_t) ersetzt (siehe auch PEP-0353, um die Vorteile einer 64bit-Architektur nutzen zu können. Mit Python 2.5 sollte also mmap mit großen Dateien funktionieren.
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

Kann dieses "sollte" jemand bestätigen? Ich habe eine x86_64 Architektur und überlege auf Python 2.5 upzudaten.
Trundle hat geschrieben:Zumindest bei der x86_64-Architektur (aka amd64) gilt sizeof(int) == 4 und (C)Python hat intern sehr oft ints benutzt, etwa beim Indizieren oder eben auch bei mmap-Objekten. Mit Python 2.5 wurden diese ints dann durch einen eigenen Datentyp (Py_ssize_t) ersetzt (siehe auch PEP-0353, um die Vorteile einer 64bit-Architektur nutzen zu können. Mit Python 2.5 sollte also mmap mit großen Dateien funktionieren.
Benutzeravatar
Trundle
User
Beiträge: 591
Registriert: Dienstag 3. Juli 2007, 16:45

BastiL hat geschrieben:Kann dieses "sollte" jemand bestätigen? Ich habe eine x86_64 Architektur und überlege auf Python 2.5 upzudaten.
Funktioniert (zumindest mit/unter/über/auf x86_64).
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

Ok, danke für die Info. Dann werde ich mal ein Update machen.

BastiL
encbladexp
User
Beiträge: 61
Registriert: Freitag 7. März 2003, 19:28
Kontaktdaten:

Was auch schön wäre: Ein der der Daten die die re durchwühlt...

Es sollte doch noch ein anderes, und vor allem schnelleres Verfahren für dein Problem geben.

mfg Betz Stefan
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

encbladexp hat geschrieben:Was auch schön wäre: Ein der der Daten die die re durchwühlt...
Das verstehe ich nicht....? Was meinst Du damit?
epsilon
User
Beiträge: 71
Registriert: Freitag 20. Juni 2008, 19:48

Das verstehe ich nicht....? Was meinst Du damit?
Ich denke, der Satz sollte eigentlich
Eine der Dateien die der re durchwühlt...
heißen ;)
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

das geht leider nicht, da die Files riesig sind und vertrauliche Daten enthalten.
BastiL
User
Beiträge: 135
Registriert: Montag 7. Juli 2008, 20:22

Also ich bin inzwischen etwas weiter:

1. habe ich Python 2.5.2 verfügbar, damit läuft "mem" und "mmap" über Files größer als 2GB

2. scheint das Thempo mit Python 2.5.2 deutlich langsamer zu sein....

Ich muss mir das noch einmal anschauen und poste die Resultate dann.
Antworten