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
Hier wäre es hilfreich zu wissen ob das für ein Windows- oder Linux/Unix-System gedacht ist...
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
@rschube das setzt aber alles Un*x oder Windows mit einem entsprechenden Toolkit voraus ;)
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? ;)
vi(m) lädt die gesamte Datei in den Speicher, ist für wirklich große Dateien also auch nicht geeignet.
>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.
Kann man nicht für so was auch irgend eine Art Datenbank verwenden?
(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
Erst auf Festplatte entpacken, danach paged öffnen. So das nur der Teil den du dir anguckst vom BS in den RAM geladen wird.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.