Das bringt endlich Licht ins Dunkel was diese Codepages sind. Danke für die Aufklärung.NicTheQuick hat geschrieben:Ich möchte nicht erneut alle Frage beantworten, aber noch etwas zu Codepages sagen. Die stammen eigentlich aus der Zeit, zu der jedes Zeichen nur 8 Bit hatte, also vergleichbar zu ASCII.
In 8 Bit kann man nur 256 verschiedene Zeichen stecken. Ein Teil davon sind Steuerzeichen, ein Teil repräsentiert das lateinische Alphabet, ein Teil Umlaute, Zeichen mit Akzenten, usw. Aber das ist nur in der Codepage so, die wir hier bei uns kennen. Es gibt noch Codepages, bei denen an Stelle unserer Buchstaben ganz andere stehen, dazu gehören Kyrillisch, griechisch, Thai, Japanisch und viele mehr. Im Grunde wird jeder Wert zwischen 0 und 255 auf ein Zeichen gemappt, das auch wieder eine bestimmte Nummer hat, die man in der Schriftartendatei finden kann. Da man auf diese Weise niemals alle Zeichen der Sprachen auf der Welt unter einen Hut kriegen konnte ohne Codepages zu wechseln, gibt es eben UTF-8, Unicode und Konsorten.
Das Problem an UTF-8 ist, dass jedes Zeichen entweder 8, 16, 24 oder 32 Bit haben kann, man also aus der Bytelänge, die ein UTF-8-String im Speicher belegt, nicht sicher die Zeichenanzahl voraussagen kann. Gleichzeitig kann man mit UTF-8 im Gegensatz zu Unicode meist annähernd die Hälfte des Speichers sparen, weil Unicode immer 2 Bytes pro Zeichen belegt. Bei UTF-8 kommt es hierzulande seltener vor, dass ein Zeichen mehr als 1 Byte belegt. UTF-8 eignet sich deswegen sehr gut im Texte in Dateien zu speichern, weil dadurch nie zu viel gespeichert wird. Unicode eignet sich im RAM besonders gut, weil man jedes Zeichen direkt ansprechen kann, weil es immer aus 2 Bytes besteht.
Aus dem Blickwinkel das mann dann nicht mehr anhand der Speicherverbrauchs sagen kann, wieviele Zeichen überhaupt ein String hat finde ich sehr intressant, so hab ich das noch gar nicht betrachted gehabt.
Also ich hab PB immer im Ascii Modus benutzt (und mich nie um die Schreibmethode gekümmernt, entweder einfach WriteString gemacht oder WriteData) und selbst erstelle Text Dateien und Server Log Auswertungen haben sowieso nur das was Ascii vor kommt.
d.H bleich ich bei solchen Tools einfach bei PB vor 5.50 und schau ob ich mit #PB_Ascii noch ein paar
ms mehr an Speed rausholen kann
Meine Tools sind alle schon seit jahren fertig geschrieben (und auch in Anwendung von mir und Kollegen) für meine Windows PC's, und die Notebooks benutzen sowieso alle nur Debian, und den Stress etwas für Linux umzuschreiben tu ich mir nicht an, selbst sowas banalesUnd jetzt erklär mal genau, was dein Programm tun muss. Ich bin sicher es gibt eine einfache Lösung, auch für dein veraltetes System. Im übrigens sind 1 Mio Zeilen ja nicht mal so viel. Wie lange sind die Zeilen denn überhaupt? Selbst bei 100 Zeichen pro Zeile verbraucht man damit ja nur 200 MB RAM bei Unicode.
wie FileFingeprint mit nem MD5 Flag hat dort unerklärlicherweise nicht funktioniert (PB 5.60, Rückgabewert war immer ein leerer String) obwohl laut install.sh Script alle Abhängigkeiten gepasst haben.
Ich kann nie genau sagen wie lang die Zeilen sind (kommt immer auf den User Agent, die ip usw an) aber wenn mann 1 Million Zeilen auf Zeichenfolgen untersuchen & Filtern lässt, und danach noch Sortiert, und dann mit einer anderen 1 Million Zeilen Log Datei abgleichen lässt auf Dupes, belegt das zum Teil temporär paar 100MB an Ram, selbst unter einem 32 Bit OS, und das Tempo wird dann auch sehr wichtig.
Da wird dann schon mal ausprobiert ob der Abgleich schneller geht, wenn jede Line auf lcase umgewandelt wird, und dann auf dupes abgeglichen
Wie gesagt die Masse an Strings machts, hab eine Proxy Judge laufen, da kommen pro Tag locker 1-2 Milllionen Zugriffe raus ist eine hervorangende Möglichkeit um an frische Free Proxys zu kommen