www.mikrocontroller.net

Forum: PC Hard- und Software Texteditor für sehr große Dateien


Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien 
(>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei 
sowas einfach ab.

Kennt jemand ein solches Programm?

Autor: David ... (volatile)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OT: Was macht man mit soOoOo grossen Dateien? Da passen doch ganze 
Bibliotheken rein...

Autor: Platinenschwenker .. (platinenschwenker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
> Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien
> (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei
> sowas einfach ab.
>
> Kennt jemand ein solches Programm?

schau mal hier

http://www.winvi.de/en/

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich stand auch schon mal vor dieser Fragestellung, leider ist es schon 
ein paar Jahre her und ich kann micht nicht mehr genau erinnern, welcher 
Editor nun funktioniert hatte.

Aber um noch ein paar auszuprobieren ;-)

http://en.wikipedia.org/wiki/List_of_text_editors

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David ... schrieb:
> OT: Was macht man mit soOoOo grossen Dateien? Da passen doch ganze
> Bibliotheken rein...

Das sind z.B. Messdaten. Teilweise würde da schon ein Textviewer reichen 
(aber sowas gibts heutzutage ja kaum noch), teilweise muss man noch eine 
Kleinigkeit ändern.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Platinenschwenker .. schrieb:
> schau mal hier
>
> http://www.winvi.de/en/

"large files upto 2 gigabyte editable"

Das ist ja schonmal ein Anfang, obwohl ich eigentlich vi nicht mag.

Danke für den Hinweis.
  Markus

Autor: Platinenschwenker .. (platinenschwenker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
> Platinenschwenker .. schrieb:
>> schau mal hier
>>
>> http://www.winvi.de/en/
>
> "large files upto 2 gigabyte editable"
>
> Das ist ja schonmal ein Anfang, obwohl ich eigentlich vi nicht mag.
>
> Danke für den Hinweis.
>   Markus

Ich benutze auch lieber z.B. diesen hier

http://www.scintilla.org/

aber ob der so große Dateien abkann? Glaub' eher nicht.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
> David ... schrieb:
>> OT: Was macht man mit soOoOo grossen Dateien? Da passen doch ganze
>> Bibliotheken rein...
>
> Das sind z.B. Messdaten.

Mag ja sein, aber wer verbietet dem Messprogramm, mehrere Dateien 
anzulegen anstatt einer riesengroßen?
Und jetzt sag bitte nicht "Es wird bereits so gemacht..." :-)))

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm. Kenne für Win auch keinen solchen Editor. Kippe es doch mal in eine 
Textverarbeitung. Die muß schließlich auch ein ganzes Buch in der 
Entwurfsfassung verwursteln können. Mit Bildern sollte da problemlos 
100MB zusammenkommen. Mit reinem Text wird es allerdings schwierig. Wie 
war das? 2000 Zeichen pro Schreibmaschinenseite. Buch ist tausend Seiten 
dick. Macht 2MB.
Für den Mac gibt es so einen Editor. Sollte es also für Win auch geben.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ultraedit kann das ohne Probleme, habe auch schon mit dateien > 4GB 
gearbeitet.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
> Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien
> (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei
> sowas einfach ab.
>
> Kennt jemand ein solches Programm?

Ich tippe auf Notepad++. Probier mal und berichte.
http://notepad-plus.sourceforge.net/de/site.htm
Hab keine so große Textdatei zur Hand aber ich erinnere mich, dass ich 
da bei einer sehr großen Datei weiter kam als mit Pspad.

Autor: Markus K. (markus-)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mark Brandis schrieb:
> Mag ja sein, aber wer verbietet dem Messprogramm, mehrere Dateien
> anzulegen anstatt einer riesengroßen?

Das könnte man machen, aber dann wird das Handling insgesamt wieder 
komplizierter. Das wollte ich vermeiden.

Abdul K. schrieb:
> Kippe es doch mal in eine
> Textverarbeitung. Die muß schließlich auch ein ganzes Buch in der
> Entwurfsfassung verwursteln können. Mit Bildern sollte da problemlos
> 100MB zusammenkommen.

100MB kann jeder Popeleditor. Das ist bloß viel zuwenig.
Außerdem sind meine Zeilen meist auch ziemlich lang (z.B. 2000 Zeichen), 
das ist mit einer Textverarbeitung typischerweise eher unpraktisch.

Helmut S. schrieb:
> Ich tippe auf Notepad++. Probier mal und berichte.
Das hatte ich schon probiert. Und Programmers Notepad2. Beide sind 
abgestürzt.

Markus

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Editor ist die eine Sache.

Es bleibt aber die interessante Frage ob Dein Meßprogramm diese Datei zu 
DIESER Zeit noch benutzt. Dann kommt die Folgefrage ob der Editor evtl. 
aktuelle Meßwerte verhindert.

Über 1GB eine neue Datei anzufangen dürfte auch von der Laufzeit und vom 
RAM her die günstigere Lösung sein?

Autor: Mano Wee (Firma: ---) (manow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier es mal mit einem Hex-Editor. Die können mit großen Dateien teils 
sehr gut umgehen und zeigen den Inhalt der Datei nicht nur in 
Hexdarstellung, sondern auch als ASCII-Text dar. Manipulation der Datei 
ist natürlich auch möglich.


Habe mal schnell für Win* nach einen gesucht und bin auf "avihex" 
gestoßen. Bei den "Features" steht an erster Stelle: "no Limit of File 
Size"

Quelle: http://www.gero-net.de/avihex/index.htm

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
UltraEdit kann sehr große Files öffnen. Es dauert aber recht lange, bis 
er sie öffnet, was vermutlich daran liegt, dass er sich eine Kopie 
anlegt. Und beim durchscrollen dauert es wieder. Das sieht dann im 
ersten Moment wie ein Absturz aus. Das ist zumindest die Erfahrung, die 
ich mit einer recht alten Version gemacht habe.

Vielleicht hättest du bei den Tests mit den anderen Editoren länger 
warten sollen?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> UltraEdit kann sehr große Files öffnen. Es dauert aber recht lange, bis
> er sie öffnet, was vermutlich daran liegt, dass er sich eine Kopie
> anlegt. Und beim durchscrollen dauert es wieder. Das sieht dann im
> ersten Moment wie ein Absturz aus. Das ist zumindest die Erfahrung, die
> ich mit einer recht alten Version gemacht habe.
ja so ist es, und weil die entwickler das wissen haben sie eine 
möglichkeit geschaffen es abzuschalten - bei den option für 
dateihandling.

Noch schnell geht es wenn man noch die Zeilennummer ausschaltet.

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem ich zu spät den Beitrag von 'Mano Wee' gesehen habe:
Sehr schnell und imho unabhängig von der Filegröße öffnet WinHex 
http://www.x-ways.net/winhex/index-d.html jeden File.
Aber dies ist ein Hexeditor und interpretiert in der ASCII-Anzeige 
leider keine Zeilenumbrüche (in meiner noch alten Version).
Die Grundfunktion gibt's für private Nutzung frei.

Peter schrieb:
>ja so ist es, und weil die entwickler das wissen haben sie eine
>möglichkeit geschaffen es abzuschalten - bei den option für
>dateihandling.
Richtig, hatte ich vergessen. Er legt dann kein Backup an.

Beide lassen übrigens die Möglichkeit zu, dass ein anderes Programm den 
File zwischenzeitlich ändert - UEDIT aber nur, wenn die von Peter 
beschriebene Option nicht aktiv ist.

Autor: Patrick Dohmen (oldbug) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus dem Bauch raus würde ich sagen, dass emacs das kann.
Der bringt auch noch ganz andere Vorteile mit sich :-D

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
> Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien
> (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei
> sowas einfach ab.
>
> Kennt jemand ein solches Programm?
Nimm' gvim (http://www.vim.org/). Zumindest unter Unix/Linux ist er nur 
an die maximele Dateigröße des Dateisystem gebunden. Ist kompatibel zum 
"Ur-vi", hat aber auch einen Kompatibilitätsmodus, so dass er ganz 
"gewöhnlich" zu bedienen ist.

Ist ein ziemlich mächtiger Editor, den ich nicht mehr missen möchte.

Gruß,
Bernd

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weder vim noch emacs sind dafür geeignet, beide laden die komplette 
Datei ins RAM.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
> 100MB kann jeder Popeleditor. Das ist bloß viel zuwenig.
> Außerdem sind meine Zeilen meist auch ziemlich lang (z.B. 2000 Zeichen),
> das ist mit einer Textverarbeitung typischerweise eher unpraktisch.
>

Nein! Die Frage ist, ob der Editor Dateien größer als die mögliche 
RAM-Zuteilung für sich selbst öffnen kann, also in Stückchen arbeitet 
und dieses richtig zusammensetzt/verwaltet.
Wenn dein PC also eh 1GB RAM hat, ist das kein Test!

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>RAM-Zuteilung
Dann schau doch mal mit systeminfo

Total Physical Memory:     ???? MB
Available Physical Memory: ???? MB
Virtual Memory: Max Size:  2.048 MB
Virtual Memory: Available: 2.007 MB
Virtual Memory: In Use:    41 MB   <=========
Page File Location(s):     x:\pagefile.sys
usw.

... ob da überhaupt der Platz reicht für Deine Experimente.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinst du mich? Ich öffne solche Riesendateien normalerweise nie. Kommen 
für mich nur als Film oder pdf vor. Und da habe ich ja die 
Spezialeditoren in Form von pdf-Reader bzw. VLC.

Wo soll 'systeminfo' eigentlich sein?

Autor: eklige Tunke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
>> Ich tippe auf Notepad++. Probier mal und berichte.
> Das hatte ich schon probiert. Und Programmers Notepad2. Beide sind
> abgestürzt.
Die Frage ist, sind die Editor wirklich abgestürzt oder brauchen sie 
noch mehr Zeit.
Ich habe mal eine exe-Datei, die Bilder als Dia-Schau angezeigt hat, mit 
dem Windows-eigenen Notepad-Ersatz geöffnet. Lass mich lügen, 
Wordpad-MFC oder so heißt der imho. Das ist knapp 8 Jahre her und war 
mit dem Notepad sehr schnell, da der sofort abstürzte mit dem Wordpad 
dauerte es 40 Minuten, ging aber.
Ansonsten solltest du mal verraten, welche du ausprobiert hast und nicht 
gehen.

Autor: eklige Tunke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:
> Wo soll 'systeminfo' eigentlich sein?
In der cmd.exe, ist imho aber nicht bei allen Windowsversionen 
vorhanden.

http://technet.microsoft.com/en-us/library/bb491007.aspx

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Wichtige an so einem Editor ist die Scroll- und Suchfunktion. Ohne 
kann's muehsam werden.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eklige Tunke schrieb:
> Abdul K. schrieb:
>> Wo soll 'systeminfo' eigentlich sein?
> In der cmd.exe, ist imho aber nicht bei allen Windowsversionen
> vorhanden.
>
> http://technet.microsoft.com/en-us/library/bb491007.aspx

Systeminformationen unter Zubehör zeigt auch solche Werte an.

Autor: EinGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit gVim konnte ich gerade eine 2.8GB Datei unter XP öffnen.
Hat etwas gedauert aber abgestürtzt ist nichts.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eklige Tunke schrieb:
> Markus Kaufmann schrieb:
>>> Ich tippe auf Notepad++. Probier mal und berichte.
>> Das hatte ich schon probiert. Und Programmers Notepad2. Beide sind
>> abgestürzt.
> Die Frage ist, sind die Editor wirklich abgestürzt oder brauchen sie
> noch mehr Zeit.

Wenn ich mich recht erinnere, dann sind beide abgestürzt. Ich könnte 
mich beim Notepad++ aber auch täuschen: Ich habe es gerade nochmal 
getestet und da zeigt sich, dass er ewig braucht, aber dabei kaum 
Rechenzeit benötigt. Das ist normalerweise schon ein deutlicher Hinweis 
auf einen Absturz. Öffnen kann er sie allerdings nicht, irgendwann sagt 
er dann, dass ihm die Datei zu groß sei.

> Ansonsten solltest du mal verraten, welche du ausprobiert hast und nicht
> gehen.

Außer dem Windows-Editoren im wesentlichen nur den erwähnten Notepad++ 
und PN2. Aber wozu willst Du das wissen? Suchst Du dann für mich im Netz 
nach besseren Editoren?
Ich hatte mir das einfach so gedacht, dass die Leute mir die Editoren 
nennen, von denen sie wissen, dass sie das können. Ganz ohne Aufwand. 
Ultraedit wurde schon genannt, der ist aber kommerziell. J-Write könnte 
das wohl auch, aber der ist ebenfalls nicht umsonst.

Markus

Autor: Andre M. (loonquawl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry für die Thread-Nekromantie, der 010-editor ist auch hervorragend, 
und für die ersten 30 Tage kostenlos....

thegun ist ... seltsam, funktioniert aber auch schön.

Autor: TheUnknown (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Thread hier ist schon ziemlich alt. Keine Ahnung ob´s noch jemandem 
nutzt, aber für solche Fälle ist unter Windows baretail von BareMetal 
Software sehr zu empfehlen. Das Programm ist kostenlos nutzbar. Baretail 
ist eigentlich ein Echtzeit-Logfile-Viewer (und blockiert damit auch 
andere schreibende Prozesse nicht). Es läd immer nur den sichtbaren 
Bereich der Datei. Der Speicherverbrauch bleibt dadurch auch bei sehr 
großen Dateien im Rahmen (< 20MB). Baretail hat zwar keine Suchfunktion, 
aber einen konfigurierbaren Highligter (Schrift- + Hintergrundfarbe je 
gesuchter Zeichenkette).

Autor: Moby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine ganz klare Empfehlung: PilotEdit. Vor allem auf schwächeren 
Systemen.

Moby

Autor: uooihzouhpo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
richtiges Betriebssystem verwenden. Das geht bei Linux mit fast jedem 
Editor. Was nicht in den Speicher (RAM) passt, wird eben auf Platte 
ausgelagert.

Autor: d'oh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jasch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
> Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien
> (>>1GB) umgehen kann. Die meisten Editoren die ich kenne stürzen bei
> sowas einfach ab.

Nun, wen wunderts? Nein, wirklich, Programmierer werden sofort sehen 
warum, auch wenn es für den Berufsstand mehr als peinlich ist...

Für so grosse Datenmengen wird ein 64-Bit-System schwer empfohlen...

> Kennt jemand ein solches Programm?

Hmm, guckst Du hier: 
http://en.wikipedia.org/wiki/Comparison_of_text_editors .

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
context solls ja auch können und kost nix.
ausserdem gibts ja immer noch sed.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann so ein Dateimonster au in handliche Brocken zerlegen und dann 
mit jedem beliebigen Editor bearbeiten.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jasch schrieb:
> auch wenn es für den Berufsstand mehr als peinlich ist...

Der Umgang mit Textdateien beliebiger Grösse war schon beim Editor HS 
von Borland für MSDOS gelöst, meine Version ist vom 19.3.1992. Dazu gabs 
sogar den Source-Text.

Irgendwann seither hat sich aber die Auffassung durchgesetzt, 
speichersparendes Programmieren sei total uncool. Selbst wenn man nur 
ein paar Bytes im Header einer Bilddatei prüfen will, lauten alle 
heutigen Empfehlungen und Musterprogramme: erstmal die Datei in den 
Speicher laden, dann sieht man weiter...

Gruss Reinhard

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Selbst wenn man nur
> ein paar Bytes im Header einer Bilddatei prüfen will, lauten alle
> heutigen Empfehlungen und Musterprogramme: erstmal die Datei in den
> Speicher laden, dann sieht man weiter...

Das ist ja i.d.R. virtueller Speicher, der bei Bedarf ausgelagert werden 
kann, ohne daß der Programmierer dafür auch nur einen Finger krumm 
machen muß. Davon konnte man zu DOS-Zeiten nur träumen...

Autor: Markus Kaufmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal davon abgesehen, dass ich die Anfrage vor 2,5 Jahren gestellt habe: 
Man kann es sich halt nicht immer aussuchen, ob man ein Betriebsystem 
mit 32 oder 64 Bit verwendet.

@Reinhard Kern:
Ja, darüber reg ich mich auch auf. Insbesondere bei Hexeditoren, denn 
bei denen müsste man einfach nur aufs Einfügen/Löschen verzichten und 
schon wirds ganz einfach zu programmieren.

Autor: b.c. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Selbst wenn man nur
> ein paar Bytes im Header einer Bilddatei prüfen will, lauten alle
> heutigen Empfehlungen und Musterprogramme: erstmal die Datei in den
> Speicher laden, dann sieht man weiter...

Das ist bei anständigen Betriebssystemen ja auch sinnvoll. Denn es 
handelt sich, wie Uhu richtig schrieb, um virtuellen Speicher, den das 
Betriebssystem nach Bedarf auf die Festplatte auslagern kann. Der 
Programmierer des Editors muss sich darum nicht kümmern. Bei Microsoft 
dauert es halt immer ein paar Jahrzehnte länger, bis sie übliche 
Techniken in ihre Produkte einbauen.

> Man kann es sich halt nicht immer aussuchen, ob man ein Betriebsystem
> mit 32 oder 64 Bit verwendet.

Dazu braucht man keine 64 Bit. Das ging vor 20 Jahren auf meinen 486er 
auch schon.

Autor: Marwin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:

> Ja, darüber reg ich mich auch auf. Insbesondere bei Hexeditoren, denn
> bei denen müsste man einfach nur aufs Einfügen/Löschen verzichten und
> schon wirds ganz einfach zu programmieren.

Warum sollte ich mir als Entwickler viel Arbeit machen fuer eine 
Nischenanwendung, noch dazu wenn ich anschliessend mit solchen 
Kommentaren rechnen muss:

> Ultraedit wurde schon genannt, der ist aber kommerziell.

Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten 
Anforderungen erfuellt.

Autor: Gratisprogger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marwin schrieb:
> Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten
> Anforderungen erfuellt.

Bitteschön:

http://www.vim.org/

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
b.c. schrieb:
> Bei Microsoft
> dauert es halt immer ein paar Jahrzehnte länger, bis sie übliche
> Techniken in ihre Produkte einbauen.

Bereits Windows NT 3.1 (1993!) kannte "memory mapped files", mit denen 
genau das beschriebene Verhalten möglich war, und das sogar recht 
effizient.
Warum keiner der üblichen Frickelprogrammierer es jemals für nötig 
gehalten hat, sich die Win32-API-Dokumentation auch mal anzusehen, das 
entzieht sich sowohl meiner Kenntnis als auch meinem Verständnis.

Autor: Verwunderter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
b.c. schrieb:
> Das ist bei anständigen Betriebssystemen ja auch sinnvoll. Denn es
> handelt sich, wie Uhu richtig schrieb, um virtuellen Speicher, den das
> Betriebssystem nach Bedarf auf die Festplatte auslagern kann. Der
> Programmierer des Editors muss sich darum nicht kümmern.

Ja - nee. Macht schon Sinn, einen Haufen Daten erstmal kopflos zu 
duplizieren, um dann in der Kopie ein paar Bytes zu Suchen, statt gleich 
im Original zu suchen, dass nicht mal mehr auf die Festplatte 
ausgelagert werden muss, weil es da schon liegt. Manche 
Programmiererlogik muss man erstmal verstehen und kann sich nur wundern.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
b.c. schrieb:
> Reinhard Kern schrieb:
>> Selbst wenn man nur
>> ein paar Bytes im Header einer Bilddatei prüfen will, lauten alle
>> heutigen Empfehlungen und Musterprogramme: erstmal die Datei in den
>> Speicher laden, dann sieht man weiter...
>
> Das ist bei anständigen Betriebssystemen ja auch sinnvoll. Denn es
> handelt sich, wie Uhu richtig schrieb, um virtuellen Speicher, den das
> Betriebssystem nach Bedarf auf die Festplatte auslagern kann.

Unnötige Daten in den Speicher laden kostet aber Zeit, und sie dann 
wieder zurück auf die Platte auszulagern kostet noch mal Zeit, und das 
nur, um sie dann zweimal auf der Platte stehen zu haben. Und dann werden 
geschickterweise noch Daten von anderen Prozessen nebenbei ausgelagert, 
so daß das dann nachher auch erstmal alles ganz langsam läuft, bis die 
Daten wieder ihren Weg in den Speicher gefunden haben.

>> Man kann es sich halt nicht immer aussuchen, ob man ein Betriebsystem
>> mit 32 oder 64 Bit verwendet.
>
> Dazu braucht man keine 64 Bit. Das ging vor 20 Jahren auf meinen 486er
> auch schon.

Höchstens bei Betriebssystemen, die mehrere 32-Bit-Datensegmente pro 
Prozess verwalten können. Mir ist keins bekannt, das das je getan hätte, 
und bei allen anderen ist der Adressraum pro Prozess eben inklusive 
reservierter Bereiche auf 4 GB beschränkt. Das konnte auch der 486er 
nicht umgehen.

Autor: Marwin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gratisprogger schrieb:
> Marwin schrieb:
>> Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten
>> Anforderungen erfuellt.
> Bitteschön:
>
> http://www.vim.org/

Mir waere neu, dass vim von Markus Kaufmann entwickelt wurde.

Autor: Markus Kaufmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marwin schrieb:
>> Ultraedit wurde schon genannt, der ist aber kommerziell.
>
> Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten
> Anforderungen erfuellt.

Es geht dabei nicht darum, ob es Geld kostet oder nicht, sondern um den 
Aufwand der Anschaffung. Ich hab das vor allem bei der Arbeit gebraucht 
(mittlerweile nicht mehr) und da ist es deutlich leichter eine 
Matlab-Lizenz zu bekommen (weil das schon eingesetzt wird) als 50€ für 
einen neuen Texteditor.

Privat ist das nicht so schwierig und da habe ich mich gegen Openoffice 
und gegen Gimp entschieden und Microsoft Office und Photoshop gekauft.

Davon abgesehen kann ich nicht nachvollziehen, warum ich mir nur 
wünschen darf, was ich auch selber gebe.

Autor: 0815 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ist der Adressraum pro Prozess eben inklusive
> reservierter Bereiche auf 4 GB beschränkt.

Es war hier aber von 1 GB die Rede.

Autor: Markus Kaufmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0815 schrieb:
>> ist der Adressraum pro Prozess eben inklusive
>> reservierter Bereiche auf 4 GB beschränkt.
>
> Es war hier aber von 1 GB die Rede.

Der Prozess-Adressraum ist typischerweise aber nur 2 oder 3 GB groß und 
da viele Editoren ASCII-Dateien intern als Unicode darstellen braucht 
man für eine 1GB ASCII-Datei eben 2GB Speicher.  Ich habe ja auch nach 
>>1GB gefragt, nicht exakt 1GB.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Kaufmann schrieb:
> Der Prozess-Adressraum ist typischerweise aber nur 2 oder 3 GB groß

Nichts hindert einen Editor daran, nur einen Teil der Datei im 
Arbeitsspeicher zu halten - mit o.g. "memory mapped files" ist das unter 
Windows seit Urzeiten möglich, da die zugehörigen Funktionen schon mit 
64-Bit-Dateizeigern gearbeitet haben, als Festplatten noch sehr 
problemlos mit 32 Bit komplett adressiert werden konnten.

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Memory-Mapping für einen Editor halte ich für - ähem - "suboptimal". 
Der Dateiinhalt ist im Fehlerfall (Editor stürzt ab, Stromausfall) 
schnell mal in einem fragwürdig-konsistenten Zustand. Hat einen guten 
Grund, dass Editoren mit Sicherungskopien oder ähnlichem arbeiten.
Für einen nur lesenden Viewer ist - bzw. wäre - Memory-Mapping 
natürlich die optimale Lösung.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zudem lässt Memory-Mapping nur sehr eingeschränkte Editoroperationen zu,
nämlich Lesen und Überschreiben. Einfügen und Löschen sind damit nicht
vernünftig realisierbar.

Für einen Hex-Editor, mit dem ein paar Bytes in einer größeren Datei
geändert werden sollen, ist Memory-Mapping prinzipiell in Ordnung, aber
eben auch nur, solange die Dateigröße die Größe des virtuellen Adress-
raums nicht überschreitet. Soll bspw. eine ganze Partition oder gar eine
Festplatte editiert werden, ist diese Bedingung auf 32-Bit-Systemen
praktisch immer verletzt.

Es ist aber auch kein großer Programmieraufwand, statt über Memory-
Mapping per seek() einzelne Dateipositionen anzufahren und dort die
entsprechenden Bytes zu modifizieren.

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> auch nur, solange die Dateigröße die Größe des virtuellen Adress-
> raums nicht überschreitet.

Die Datei muss nicht vollständig gemappt werden. Das läuft dann eben wie 
bei seek(), nur ohne die Daten einzulesen.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0815 schrieb:
>> ist der Adressraum pro Prozess eben inklusive
>> reservierter Bereiche auf 4 GB beschränkt.
>
> Es war hier aber von 1 GB die Rede.

Markus Kaufmann schrieb:
> Ich suche einen kostenlosen Texteditor für Win32, der mit großen Dateien
> (>>1GB) umgehen kann.

">>1GB" heißt für mich soviel wie "Sehr viel größer als 1 GB".

Autor: JoJo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze PilotEdit Lite Freeware für grosse Text Dateien. Soll bis zu 
10 GB können.

http://www.pilotedit.com/


PilotEdit kann noch mehr, kostet aber was.

Autor: Udo Schmitt (urschmitt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EmEditor

Autor: Schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
010 Editor

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind beide nicht kostenlos!

Autor: Schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:
> Sind beide nicht kostenlos!

Ach ja, hast recht. Die Leute wollen ja immer beste Ware, aber 
kostenlos... Hatte ich vergessen.

Autor: Edi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GigaEdit ist kostenlos und gut für grosse Dateien

Autor: Edi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GigaEdit ist gut für grosse Text Dateien, ist gratis und portabel, aber 
ohne undo, dafür sehr schnell

Autor: Edi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JujuEdit kann grosse Text Dateien öffnen und ist gratis

Autor: riesige textdatei öffnen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
baretail hat mir heute eine 10GB Datei in Null komma nix geöffnet.

Beitrag #3903650 wurde von einem Moderator gelöscht.
Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verwunderter schrieb:
> Macht schon Sinn, einen Haufen Daten erstmal kopflos zu
> duplizieren, um dann in der Kopie ein paar Bytes zu Suchen, statt gleich
> im Original zu suchen, dass nicht mal mehr auf die Festplatte
> ausgelagert werden muss, weil es da schon liegt.

Wer sagt, dass die kopiert werden müssen? Moderne Betriebssysteme können 
beliebige Dateien in den virtuellen Speicher mappen und bauen zum Laden 
der Datei nur die internen Zugriffstrukturen auf.

> Manche Programmiererlogik muss man erstmal verstehen und kann sich nur
> wundern.

Da hast du wohl was nicht so ganz verstanden und wunderst dich jetzt 
auch noch darüber...

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb im Beitrag #3903650:
> Schorsch schrieb:
>> Abdul K. schrieb:
>>> Sind beide nicht kostenlos!
>>
>> Ach ja, hast recht. Die Leute wollen ja immer beste Ware, aber
>> kostenlos... Hatte ich vergessen.
>

Warum sollten nur Softwerker was bekommen?

Hier meine PayPal-Adresse leapfrogs@arcor.de für Auskünfte, die ich im
Forum oft gebe.

Danke - Abdul

Autor: Michael Steinbauer (Firma: Steinbauer Electronics GmbH) (captain-stone)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick Dohmen schrieb:
> Aus dem Bauch raus würde ich sagen, dass emacs das kann.
> Der bringt auch noch ganz andere Vorteile mit sich :-D

Bin ich ganz Deiner Meinung.


Andreas Schwarz schrieb:
> Weder vim noch emacs sind dafür geeignet, beide laden die komplette
> Datei ins RAM.

Ist das wirklich so? VIM weiß ich nicht. Aber bei meinem Traumeditor 
Emacs hat es mich jetzt interessiert. Meine Emacs Bücher haben sich dazu 
ausgeschwiegen. Ich hatte noch nie mit sehr großen Dateien Probleme. Hab 
nämlich auch schon Gigabyte große Messdateien, wie der Fragesteller 
gehabt. Folgendes hab ich dazu aber gefunden:

/Old versions (i.e., anything before 19.29) of GNU Emacs had problems 
editing files larger than 8 megabytes. As of version 19.29, the maximum 
buffer size is at least 2^27-1, or 134,217,727 bytes. On a 64bit system, 
the limit is pushed to 2^59-1 which is almost a million Terabytes./

Wenn ich das richtig verstanden habe, dann liegt die Grenze nicht am RAM 
sondern an der Adressierbarkeit. LISP benutzt einen Integer Wert dafür, 
der wiederum ist bei einem 32 Bit System anders, als bei einem 64 Bit 
System.

Jetzt könnten wir einen Feldversuch machen, eine Text Datei erstellen, 
die größer als das installierte RAM ist - C-x C-f und schauen was 
passiert :-)
(abgesehen von der Warnung, die in Emacs integriert ist, wenn eine Datei 
eine voreingestellte Größe überschreitet).

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Steinbauer schrieb:
> Jetzt könnten wir einen Feldversuch machen, eine Text Datei erstellen,
> die größer als das installierte RAM ist - C-x C-f und schauen was
> passiert :-)

"Das RAM" ist virtueller Speicher.

Autor: Michael Steinbauer (Firma: Steinbauer Electronics GmbH) (captain-stone)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> "Das RAM" ist virtueller Speicher.

Also auch ausgelagert auf Festplatte meinst Du? Ich weiß nicht, ob das 
Andreas Schwarz auch so gemeint hat. Ich hatte das anders verstanden.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Steinbauer schrieb:
> Also auch ausgelagert auf Festplatte meinst Du?

Beitrag "Re: Texteditor für sehr große Dateien"

Beitrag #3906329 wurde von einem Moderator gelöscht.
Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn der Thread schon etwas lange andauert. Ich habe nun eine Weile 
nach einem Editor gesucht um damit Daten jenseits der 7GB zu öffnen, zu 
editieren und wieder zu speichern. Generell bin ich ein Fan von Uedit- 
bis 2GB ging das auch prima damit aber die Problemfälle jenseits der 6GB 
waren ihm zu groß. Gun ist phänomenal schnell -selbst Dateien mit über 
20GB lassen sich unglaublich schnell öffnen- aber beim speichern der 
veränderten Daten kürzt er die Datei auf ca. 1GB ein. Für "kleinere" 
Dateien bis 2GB ist das meine erste Wahl.

Etwas langsam aber zuverlässig ist PilotEdit und damit werde ich nun die 
Problemfälle anpacken.

Um den üblichen Diskurs zu unterbinden: das sind hochauflösende 
Laserscandaten und mein System hat 32GB RAM dessen Speicherverlauf auch 
beim Abbruch der meisten Editoren unauffällig ist.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Generell bin ich ein Fan von Uedit-
> bis 2GB ging das auch prima damit aber die Problemfälle jenseits der 6GB
> waren ihm zu groß.

hast du auch die Option gesetzt, das die Datei direkt geöffnet wird?

Musstest du Daten entfernen und einfügen oder nur überschreiben?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das eigentliche Problem scheint doch zu sein: Warum in drei Teufels 
Namen willst Du so eine Datei in einem Text-Editor öffnen, doch sicher 
nicht um sie zu lesen, oder? Kein Mensch kann 1GB Text in sinnvoller 
Zeit lesen.

Du möchtest wahrscheinlich entweder

* die Daten filtern und/oder Zusammenfassen so daß nur noch die 
eigentlich interessante Information zusammengefasst in wenigen Zeilen 
übrig bleibt.

* die Daten automatisiert umformatieren

In beiden Fällen wäre eine entsprechend geeignete Scriptsprache (viele 
würden hier ganz klassisch Perl vorschlagen aber viel andere gehen auch, 
je nach Problemstellung) als Werkzeug die weitaus bessere Wahl als ein 
Texteditor.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Um den üblichen Diskurs zu unterbinden: das sind hochauflösende
> Laserscandaten und mein System hat 32GB RAM dessen Speicherverlauf auch
> beim Abbruch der meisten Editoren unauffällig ist.

Nun, die "meisten Editoren" werden vermutlich auch 32-Bit-Programme sein 
und können damit eh nur 2 GB nutzen.

Autor: mar IO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In letzter Zeit habe den Editor Sublime 3 beta oft benützt. Der ist gar 
ned so schlecht. Eine ca. 850 MB großes Image hat dieser ohne Probleme 
geöffnet. Hat aber doch ne gute Minute gedauert, bis dieser diese offen 
hatte. Scrollen ging überraschender weise flott. Mehr habe ich aber auch 
ned ausprobiert.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.