Hallo,
ich habe hier ein paar Dateien zwischen 1 und 100 GByte auf der
Festplatte. Die Daten dieser Dateien sollen schnell und effizient am
Bildschirm angezeigt werden (immer nur eine Datei für sich).
Ich stelle mir das so vor, dass ich 3 speicherbasierte Dateien erstelle
mit jeweils 1 GByte. Somit befinde ich mich immer in einem 1 GByte
großen Datenraum, welcher nach unten bzw. oben wiederum mit einer 1
GByte großen Datei gepuffert ist.
Wenn ich jetzt den Bereich verlasse (nach oben oder unten), dann schalte
ich 'einfach' auf die entsprechende speicherbasierte Datei um und die
freigewordene Datei nimmt neue Daten auf.
In der Theorie klingt das ganz gut aber ich frage mich, ob ich das nicht
einfacher lösen kann? Ich bin für jede Hilfe dankbar!
Gruß Hans
ich versteh das Problem nicht. Du kannst doch einfach 1Mbyte aus der
Datei lesen und auf dem Bildschrim darstellen.
anhand des Scollbalkens kannst du die Position errechnen welche du
auslesen musst. Genau wird das eh nicht, weil für 100GB der Scrollbalken
viel zu grob ist.
Hallo Peter II,
es sollen nicht alle Daten auf einmal dargestellt werden, aber es soll
möglich sein, ohne 'spürbare' Verzögerung durch die Daten zu scrollen.
Deshalb auch der geplante Aufwand mit den speicherbasierten Dateien. Ich
verspreche mir davon, keine Verzögerungen durch Nachladen von der
Festplatte zu erhalten.
Gruß Hans
Hans schrieb:> Deshalb auch der geplante Aufwand mit den speicherbasierten Dateien. Ich> verspreche mir davon, keine Verzögerungen durch Nachladen von der> Festplatte zu erhalten.
normale festplatte haben ein zugriffszeit von 15ms - ich glaube das
merkt keiner. Auserdem hat jedes BS auch einen Cache für soetwas.
Lade dir mal UltraEdit (gibt es als 30Tage testversion) dort geht das
ohne Probleme und das Programm braucht keine 1GB ram.
Was erhoffst du dir in einer 100GB Datei zu finden, wenn man jeweils nur
0,00000001% der Datei sieht.
Was sind für dich "speicherbasierte Dateien"?
Du machst dir zu viele Gedanken; mmap()-e die Dateien (64 Bit-System
vorausgesetzt), greife einfach auf das zu was du darstellen willst, und
überlass dem Betriebssystem den Rest.
Bei sehr grossen Dateien öffne ich einfach in einer Konsole vi. Da hatte
ich mit GB grossen Dateien noch nie Probleme. Scrollen, Suchen etc gehen
das sehr schnell. Wo ist das Problem?
Ansonsten kann man auch mit tail -f sich Dateien anzeigenlassen.
Damit hab ich sogar schon mal StarWars in ASCII-Art geguckt.
mfg Rene
Andy D. schrieb:> @rschube das setzt aber alles Un*x oder Windows mit einem entsprechenden> Toolkit voraus ;)
Un*x oder Linux geht auch, gibt es denn sonst noch etwas anderes? ;)
>Hier wäre es hilfreich zu wissen ob das für ein Windows- oder>Linux/Unix-System gedacht ist...
Ich programmiere mit CodeBlocks/MinGW/wxWidgets - momentan unter Windows
(soll aber irgendwann auch unter Linux laufen).
Was ich vergessen habe ist, dass die Daten auf der Festplatte gepackt
sind und ich gehe davon aus, dass das Entpacken zu lange dauert. Deshalb
will ich das vorab im Hintergrund erledigen und deshalb auch die
speicherbasierten Dateien (Memory Mapped Files).
>Was erhoffst du dir in einer 100GB Datei zu finden, wenn man jeweils nur>0,00000001% der Datei sieht.
Finden will ich nichts, aber Visualisieren.
>Du machst dir zu viele Gedanken;
Das kann sein. Ich muss es wohl oder übel ausprobieren.
>Bei sehr grossen Dateien öffne ich einfach in einer Konsole vi.
Es soll eine eigenständige Software entwickelt werden. Wie mir da vi(m)
weiterhelfen soll versteh ich nicht.
Gruß Hans
Hans schrieb:> Deshalb> will ich das vorab im Hintergrund erledigen und deshalb auch die> speicherbasierten Dateien (Memory Mapped Files).
das hilft dir bei gepackten daten auch nicht weiter, dann dann hast du
in dem Speicher auch nur gepackte daten. Und Selbst wenn du 2GB ram
nutzt, was ist wenn der Nutzer in den 100GB zu einer andernen Stelle
springt, die wahrscheinlichkeit ist verdammt hoch, das er nicht in
deinem 2GB bleibt. Damit muss du wieder 2GB laden auch wenn nur nur 1Mb
davon anzeigst.
Zum schluss brauchst du viel mehr Resourcen als wenn du nur das lädst
was der nutzer sehen willst.
>das hilft dir bei gepackten daten auch nicht weiter, dann dann hast du>in dem Speicher auch nur gepackte daten.
Ich schreibe nicht 1:1 in die speicherbasierte Datei, zuerst wird
entpackt.
>was ist wenn der Nutzer in den 100GB zu einer andernen Stelle>springt, die wahrscheinlichkeit ist verdammt hoch, das er nicht in>deinem 2GB bleibt.
Das kann ich natürlich nicht ausschließen. Wie ich das löse? Keine
Ahnung - deshalb dieser Thread:).
Jedenfalls brauch ich für 1 GB Daten einlesen und entpacken ca. 5
Sekunden und das ist viel zu viel, um sie dann auch noch 'flüssig'
anzeigen zu können.
Hans schrieb:> Jedenfalls brauch ich für 1 GB Daten einlesen und entpacken ca. 5> Sekunden und das ist viel zu viel, um sie dann auch noch 'flüssig'> anzeigen zu können.
dann entpack doch nur 1Mbyte mehr passt auch nicht auf dem Bildschirm -
die Frage ist ob die einfach so zwischen drin entpacken kannst.
(ich nehme an es geht um "grafisch darstellen")
wenn man 200GByte an KOMPRIMIERTEN daten in eine (klassische) DB
schreibt, braucht er vermutlich ein paar TByte
das wirds nicht spielen
ich würd es allerdigs auch so machen, wie im eröffnungsposting
vorgeschlagen, ABER natürlich mit "kleinerer brocken"
also erstmal die aktuelle position aus der datei laden, entpacken (z.b.
10MBYte)
das anzeigen
und in einem separaten Thread (low priority) die folgenden 10MBYte und
die vorherigen 10MYbte lesen,
und dass halt 2-3 "blöcke"
so wie (jedes?) bildanzeigeprogramm ja auch das/die nächsten JPG schon
einließt (pre-caching usw.)
bewegt man sich dann einen block weiter, wird (in dem extra thread) der
"am weitesten entfernte" glöscht... und ein neuer gelesen
alternativ/zusätzlich natürlich die daten (auch) aggregieren
also aus den "blöcken" auch mehrere mit "geringerer auflösung" die nur
durchschnittswerte über bestimmte zeiträume enthalten, zur schnelleren
darstellung
insgesamt ist aber überlegenswert, ob man nicht "Nur" eine
"schnittstelle" zu einer existierenden (profi) software erstellt
>wenn man 200GByte an KOMPRIMIERTEN daten in eine (klassische) DB>schreibt, braucht er vermutlich ein paar TByte
Die Daten lassen sich recht gut packen, so dass das Verhältnis bei etwa
1:100 liegt. Außerdem ist es so, dass die entpackten Daten im
GByte-Bereich liegen (momentan teste ich mit 1 GByte-Dateien, die auf
der Festplatte dann ca. 10 MByte belegen).
>Kann man nicht für so was auch irgend eine Art Datenbank verwenden?
Der Datenbankzugriff macht das Ganze vermutlich noch einmal etwas
langsamer.
>dann entpack doch nur 1Mbyte mehr passt auch nicht auf dem Bildschirm
Damit ist es nicht getan. Ich muss schon größere Datenmengen darstellen
(wenn auch nur in komprimierter Form).
Vielen Dank soweit für die gemachten Tipps und Denkanstöße. Ich stelle
fest, dass diese Problemstellung wohl eher selten vorkommt. Ich werde
jetzt mal einiges versuchen und ausprobieren. Dann seh ich weiter.
Gruß Hans
Hans schrieb:> Die Daten lassen sich recht gut packen, so dass das Verhältnis bei etwa> 1:100 liegt. Außerdem ist es so, dass die entpackten Daten im> GByte-Bereich liegen (momentan teste ich mit 1 GByte-Dateien, die auf> der Festplatte dann ca. 10 MByte belegen).
Also mir ist jetzt nicht ganz klar was jetzt wie groß ist.
- Ist deine Datei 100G gepackt oder ungepackt?
- Was stellst du dar? Daten grafisch oder als (Hex) Textdaten?
- Welcher Sinn macht es mehr als 10 (20 Seiten) zu puffern? Also warum 1
GByte vorher/nachher als Puffer.
- Du weisst schon daß bei einem Windows 32 Bit System bei knapp 2GByte
die maximale Speichergrenze für ein Programm erreicht ist?
- Mit 100 fach kleineren Daten zu testen und daraus
Performanceüberlegungen abzuleiten ist wenig aussagekräftig.
Hast du mal ausgerechnet wie viele Seiten eine 100G Datei ergibt und wie
lange man braucht um sich jede Seite auch nur 1 Sekunde anzuschauen?
- Eine Datenbank ist nur dann langsamer wenn man sie nur zur
sequentiellen Speicherung nutzt.
... to be continued.
