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?
OT: Was macht man mit soOoOo grossen Dateien? Da passen doch ganze Bibliotheken rein...
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/
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
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.
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
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.
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..." :-)))
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.
Ultraedit kann das ohne Probleme, habe auch schon mit dateien > 4GB gearbeitet.
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.
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
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?
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
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?
> 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.
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.
Aus dem Bauch raus würde ich sagen, dass emacs das kann. Der bringt auch noch ganz andere Vorteile mit sich :-D
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
Weder vim noch emacs sind dafür geeignet, beide laden die komplette Datei ins RAM.
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!
>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.
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?
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.
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
Das Wichtige an so einem Editor ist die Scroll- und Suchfunktion. Ohne kann's muehsam werden.
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.
mit gVim konnte ich gerade eine 2.8GB Datei unter XP öffnen. Hat etwas gedauert aber abgestürtzt ist nichts.
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
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.
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).
Meine ganz klare Empfehlung: PilotEdit. Vor allem auf schwächeren Systemen. Moby
richtiges Betriebssystem verwenden. Das geht bei Linux mit fast jedem Editor. Was nicht in den Speicher (RAM) passt, wird eben auf Platte ausgelagert.
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 .
context solls ja auch können und kost nix. ausserdem gibts ja immer noch sed.
Man kann so ein Dateimonster au in handliche Brocken zerlegen und dann mit jedem beliebigen Editor bearbeiten.
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
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...
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.
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.
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.
Marwin schrieb: > Ich warte gespannt auf deinen Gratiseditor, der die von dir genannten > Anforderungen erfuellt. Bitteschön: http://www.vim.org/
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.
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.
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.
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.
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.
> ist der Adressraum pro Prozess eben inklusive > reservierter Bereiche auf 4 GB beschränkt. Es war hier aber von 1 GB die Rede.
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.
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.
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.
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.
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.
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".
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.
Abdul K. schrieb: > Sind beide nicht kostenlos! Ach ja, hast recht. Die Leute wollen ja immer beste Ware, aber kostenlos... Hatte ich vergessen.
GigaEdit ist gut für grosse Text Dateien, ist gratis und portabel, aber ohne undo, dafür sehr schnell
baretail hat mir heute eine 10GB Datei in Null komma nix geöffnet.
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...
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
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).
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.
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.
Michael Steinbauer schrieb: > Also auch ausgelagert auf Festplatte meinst Du? Beitrag "Re: Texteditor für sehr große Dateien"
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.
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?
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.
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.
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.
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.