Hallo zusammen,
ich match emit einem RE einen Bereich in einem File der größer als 2GB ist. Dann bekomme ich mit m.end für den Endindex einen negativen Wert, d.h irgend etwas läuft da über.... Da ich diesen Index brauche bin ich jetzt am überlegen, wie ich den anders bekommen könnte? Ideen sind willkommen.
Grüße
RE und Python 2.5.2: Probleme beim Matching von > 2GB
- Defnull
- User
- Beiträge: 778
- Registriert: Donnerstag 18. Juni 2009, 22:09
- Wohnort: Göttingen
- Kontaktdaten:
Dazu solltest du uns vielleicht verraten, was das für Daten sind und wie dein re bisher aus sieht? RE ist nützlich, man kann aber nicht alles damit machen.
Bottle: Micro Web Framework + Development Blog
Sorry, BastiL, aber Kristallkugeln sind nicht in der Python Standardlib.Defnull hat geschrieben:Dazu solltest du uns vielleicht verraten, was das für Daten sind und wie dein re bisher aus sieht?
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Die Batterien dafuer sind aber dabei!CM hat geschrieben:Sorry, BastiL, aber Kristallkugeln sind nicht in der Python Standardlib.
Vllt sollte man ein Aequivalent zu `antigravity` vorschlagen?
Michael Markert ❖ PEP 8 Übersetzung ❖ Tutorial Übersetzung (3.x) ⇒ Online-Version (Python 3.3) ❖ Deutscher Python-Insider ❖ Projekte
Also: mein Re sieht so aus:
Die Daten sind vertraulich, aber das Schema ist dieses:
Einige MB
(0 "Grid:"
einige GB Daten
(0 "Thread variables:"
einige MB
Sofern der Bereich "einige GB" kleiner als 2GB ist läuft alles wie es soll. Ich versuche unter anderem, den Bereich ab (0 "Thread variables" bis zum Dateiende anzusprechen und verwende dazu
Dieser Ausdruck wird negativ, sobald einge GB > 2GB wird.... Ich denke das ist ein Python-internes Problem. Was ich schon versucht habe:
- Statt auf den Mittelteil der Datei auf das Ende zu matchen - dann wird das Suchen SEHRSEHR viel langsamer. Das will ich nicht.
Code: Alles auswählen
ausdruck=re.compile(r'\(0 "Grid:"\).*(?s)(?=\(0 "Thread variables:"\))').search(File, re.I)
Einige MB
(0 "Grid:"
einige GB Daten
(0 "Thread variables:"
einige MB
Sofern der Bereich "einige GB" kleiner als 2GB ist läuft alles wie es soll. Ich versuche unter anderem, den Bereich ab (0 "Thread variables" bis zum Dateiende anzusprechen und verwende dazu
Code: Alles auswählen
ausdruck.end(0)
- Statt auf den Mittelteil der Datei auf das Ende zu matchen - dann wird das Suchen SEHRSEHR viel langsamer. Das will ich nicht.
Wenn `n` die negative Zahl ist, kommt dann bei ``(-n ^ 0xffffffff) + 1`` der richtige Offset heraus? Dann wäre das zumindest schon einmal eine Notlösung.
Edit: Darf ich mal nach dem Sinn von `re` bei diesem simplen Ausdruck fragen? Da kann man doch auch mit `index()` bzw. `find()` arbeiten!?
Edit: Darf ich mal nach dem Sinn von `re` bei diesem simplen Ausdruck fragen? Da kann man doch auch mit `index()` bzw. `find()` arbeiten!?
Werde ich testen.BlackJack hat geschrieben:Wenn `n` die negative Zahl ist, kommt dann bei ``(-n ^ 0xffffffff) + 1`` der richtige Offset heraus? Dann wäre das zumindest schon einmal eine Notlösung.
Ja - es geht bei der speziellen Struktur der Files so deutlich schneller. Der Teil "einige GB Daten" enthält Binärdaten die die Suche offensichtlich ganz erheblich ausbremsen. Wir reden hier von ein paar ms im Vergleichzu mehreren Minuten Dauer zum durchsuchen....Edit: Darf ich mal nach dem Sinn von `re` bei diesem simplen Ausdruck fragen? Da kann man doch auch mit `index()` bzw. `find()` arbeiten!?
- pillmuncher
- User
- Beiträge: 1484
- Registriert: Samstag 21. März 2009, 22:59
- Wohnort: Pfaffenwinkel
Some people, when confronted with a problem,BlackJack hat geschrieben:Edit: Darf ich mal nach dem Sinn von `re` bei diesem simplen Ausdruck fragen? Da kann man doch auch mit `index()` bzw. `find()` arbeiten!?
think "I know, I'll use regular expressions."
Now they have two problems. -- Jamie Zawinski
[edit]
Ich gehör auch zu diesen Leuten.
[/edit]
In specifications, Murphy's Law supersedes Ohm's.
@BastiL: Also bei *dem* regulären Ausdruck kann eine Lösung mit `find()` nicht wirklich langsamer sein.
Das dachte ich auch. Ich werde am Montag nochmal ein Benchmark fahren. Der reguläre Ausdruck ist für eine Datei dieser Größe einfach sensationell schnell..... Ich weiss auch nicht warum.BlackJack hat geschrieben:@BastiL: Also bei *dem* regulären Ausdruck kann eine Lösung mit `find()` nicht wirklich langsamer sein.
Es wundert mich überhaupt, dass Strings mit mehr als 2 GB Daten funktionieren. Ist das eine 64-Bit-Version von Python? Falls nein, würde ich empfehlen, eine solche zu benutzen, denn ich denke nicht, dass eine 32-Bit-Version mit 4-Byte-Integern über die 2**31-1-Grenze für Strings und ihre Indices kommen kann. Falls du kein 64-Bit-Betriebssystem hast, bleibt dir nur, das ganze in mehreren Teilen zu untersuchen.
Stefan
Stefan
Das funktioniert so. Notlösung gefundenBlackJack hat geschrieben:Wenn `n` die negative Zahl ist, kommt dann bei ``(-n ^ 0xffffffff) + 1`` der richtige Offset heraus? Dann wäre das zumindest schon einmal eine Notlösung.
Dabei ist das Problem, dass die Datei per mmap in den Hauptspeicher gelesen wird und damit offensichtlich kein String ist. Deshalb konnte ich gerade kein Benchmark zur Performencekontrolle fahren, um find() mit dem regEx zu vergleichen. Geht das irgendwie, ein mit mmap eingelesenes File mit find() zu bearbeiten?Darf ich mal nach dem Sinn von `re` bei diesem simplen Ausdruck fragen? Da kann man doch auch mit `index()` bzw. `find()` arbeiten!?
Vielleicht mit dem deprecated find aus dem String-Modul?MfG
HWK
Code: Alles auswählen
string.find(mmap, substring)
HWK
Ich habe inzwischen festgestllt, das find() doch geht. rfind sollte laut mmap-Doku auch gehen tut bei mir aber nicht. Rindex und index gehen nicht, wie auch in der Doku beschrieben.
Die Suchzeit verändert sich für ein 3,7 GB-File von wenigen ms (mit regex) auf 12,4s mit find. Daher ist find für mich schlicht zu langsam und ich verwende die vorgeschlagene Notlösung.
Die Suchzeit verändert sich für ein 3,7 GB-File von wenigen ms (mit regex) auf 12,4s mit find. Daher ist find für mich schlicht zu langsam und ich verwende die vorgeschlagene Notlösung.