TMemo-Ersatz mit mehr Kapazität?

[p80286]

Hallo Zusammen,

nachdem das eingebaute TMemo bei 280MB die Grätsche macht, suche ich einen Ersatz.
Alles was das Leben bunt und komfortabel macht ist vollkommen unnötig.

Zitat:

Im Projekt XXXXX ist eine Exception der Klasse EInvalidOperation aufgetreten. Meldung: 'Text überschreitet Memo-Kapazität'. Prozess wurde angehalten. Mit Einzelne Anweisung oder Start fortsetzen.

Kennt Ihr da etwas, oder könnt Ihr etwas empfehlen?

(warum soll ich das Ding neu programmieren, wenn es schon etwas gibt?)

Gruß
K-H

[nuclearping]

Tritt das Problem auch auf, wenn du ein TRichEdit verwendest?

Die andere Frage: Warum willst du 280MB Text (auf einmal) auf dem Bildschirm anzeigen? :stupid: :mrgreen:

[p80286]

Zitat:

Zitat von nuclearping (Beitrag 1244684)

Tritt das Problem auch auf, wenn du ein TRichEdit verwendest?

Gute Idee! Scheint zu funktionieren!

Zitat:

Zitat von nuclearping (Beitrag 1244684)

Die andere Frage: Warum willst du 280MB Text (auf einmal) auf dem Bildschirm anzeigen? :stupid: :mrgreen:

Gute Frage! Da ich etwas mehr möchte als nur Anzeigen, schien mir TMemo eine gute Wahl zu sein.
Es knallt übrigens bei SetTextStr.

Delphi-Quellcode:

procedure TStrings.LoadFromStream(Stream: TStream);
var
  Size: Integer;
  S: string;
begin
  BeginUpdate;
  try
    Size := Stream.Size - Stream.Position;
    SetString(S, nil, Size);
    Stream.Read(Pointer(S)^, Size);
    SetTextStr(S);
  finally
    EndUpdate;
  end;
end;

Gruß
K-H

[Union]

Dann beobachte mal den tatsächlichen Speicherbedarf. Ggf. stellst Du dann auf 64 bit um ;)

[himitsu]

Bedenke, daß du den Text hier eventuell 3 Mal im Arbeitsspeicher hast.

- im Stream (je nach Typ)
- im String
- und dann nochmal im Memo

Bei Unicode-Delphis (2009+) sind die Daten dann auch noch doppelt so groß.

Es sind also 850 MB nötig und davon je 3 Mal mindestens 280 MB "zusammenhängend", was nicht so einfach zu finden ist.

[jaenicke]

Zitat:

Zitat von p80286 (Beitrag 1244695)

Gute Frage! Da ich etwas mehr möchte als nur Anzeigen, schien mir TMemo eine gute Wahl zu sein.

Lässt sich das nicht vor der Anzeige nonvisuell erledigen?

Je nachdem was du vorhast, könnte es sich lohnen die Anzeige selbst zu übernehmen und nur den aktuellen Teil der Datei wirklich auszulesen und anzuzeigen.

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1244708)

Es sind also 850 MB nötig und davon je 3 Mal mindestens 280 MB "zusammenhängend", was nicht so einfach zu finden ist.

Jo beim Testen hab ich mal auf den Taskmanager geschaut, das Programm krallt sich ein gutes Gigabyte.

Zitat:

Zitat von jaenicke (Beitrag 1244716)

Lässt sich das nicht vor der Anzeige nonvisuell erledigen?

Leider nein, ich weiß nicht was reinkommt, und an Hand der angezeigten daten enscheide ich was gemacht wird (Textverarbeitung nach alter Väter Sitte).

Zitat:

Zitat von jaenicke (Beitrag 1244716)

Je nachdem was du vorhast, könnte es sich lohnen die Anzeige selbst zu übernehmen und nur den aktuellen Teil der Datei wirklich auszulesen und anzuzeigen.

Naja für die reine Anzeige hab ich auch etwas sparsames in der Schublade. Aber für ein "Find and Replace" wäre es ganz schön einfach aus dem angezeigten Text heraus zu kopieren.

(nicht daß einer auf dumme Gedanken kommt, alle Aktionen auf dem Text laufen über Tstrings/Tstringlist)

@Nuclearping
im Prinzip funktioniert das Einlesen, nur das Wegschreiben erfolgt leider im RTF-Format, daran könnte man bestimmt drehen. Und die Performance ist leider vollkommen indiskutabel.

Gruß
K-H

[Lemmy]

Hi,

nur am Rande: Bin selbst kein vi-Kenner, aber nachdem ich ein 1 GByte großes MySQL Dump manuell bearbeiten musste, ist es inzwischen zu einem Tool geworden, das ich dafür halt nutze. Alles andere hat schlicht versagt. Und zum selbst programmieren fehlt mir schlicht die Zeit..

Wenn Du also ein Linux zur Hand hast: Nutze es und erfinde das Rad nicht neu... ;-)

Grüße

[p80286]

Vielen Dank nochmal an alle.
Ich habe ein wenig "nonvisuell" erledigt und es dann doch geschaft, die Datei zu laden.
Bei dem Ladevorgang (TMemo.LoadfromFile) schnellte der Speicherbedarf auf ca 1,6 GByte hinauf.
Nachdem Die Anzeige Erfolgt war, waren es nur noch 550 MB.
Bei einem Bearbeitungsschritt

Delphi-Quellcode:

TStringlist.Text:=TMemo.Lines.Text;
{Machwas}
TMemo.Lines.Text:=Tstringlist.Text;

immer noch ca 1,3 GByte.

Da ist wohl noch Optimierungspotential.

Gruß
K-H

[Union]

Zitat:

Zitat von p80286 (Beitrag 1244753)

Leider nein, ich weiß nicht was reinkommt, und an Hand der angezeigten daten enscheide ich was gemacht wird (Textverarbeitung nach alter

Du wirst ja wohl nicht alle Datenformate der Welt unterstützen bzw. verarbeiten wollen? Du kannst doch sicherlich eine Fallunterscheidung programmieren. Schließlich triffst Du die ja auch manuell beim Betrachten des Memo-Inhaltes.

[himitsu]

Zitat:

Delphi-Quellcode:

TStringlist.Text:=TMemo.Lines.Text;

Memo.Lines.Text (wobei Lines ein TMemoStrings ist) oder TStrings.Text / TStringList.Text .......

Bei einer TStringList sind alle Lines einzelne Strings.
TStringList.Text erstellt einen großen String, aus den vielen ein Einzelstrings und das wird erst zugewiesen.
Bei TStringList.Assign und TStringList.AddStrings werden die Strings aber einzeln übergeben, ohne wie erst zusammenzusetzen und dann wieder auseinanderzunehmen, weswegen

Delphi-Quellcode:

TStringList.Text := TStringList.Text

praktisch der absolute Overkill ist.

Es kommt aber immer darauf an, wie der Speicher hinter TStrings verwaltet wird und wie gut die Methoden des TStrings darauf abgestimmt sind.
So macht z.B. ein Memo.Lines.Text das Selbe wie Memo.Text und liest nicht erst "langsam" die einzelnen Lines aus, welche danach wieder zusammengesetzt werden müssten.



PS: Da du dich an den Grenzen des Speichermanagements bewegst ...
Es brauchten nur ein paar Bytes einen der großen den freien Speicherblöcke teilen, welche du grade noch so verwendet hast und schon war es das. *peng*