Hallo NG,

Ich habe eine Kurze Frage.

Ich lese unter anderem Dateien die 200 Mb Gross sind oder auch 500MB,
die meisten sind aber kleiner. Vieleicht ist das auch eine Unglückliche
Lösung die ich da habe.

Wie kann ich eine Speicherproblematik bei Byte[] umgehen oder aussschalten?

Ist vieleicht ein Stream besser, obwohl im Speicher die Abarbeitung
flotter ist?

Ich frage, weil ich nicht alles auf Stream umschreiben will, wenn es
vieleicht eine Lösung mit Byte[] gibt.

Hier der Source des Übeltäters
(in abgewandelter Form im Internet zu finden)

//dieses gibt es auch in umgekehrter Weise
private byte[] StrToByteArray(string str)
{
Encoding enc = Encoding.Default;
return enc.GetBytes(str);
}

--
Liebe Gruesse Richie
http://bmss.homelinux.org/
Wenn du denkst, du denkst, dann denkst du nur du denkst, drum denke nie
gedacht zu haben, denn das Denken von Gedanken ist gedankenloses denken.

FakeAddress schrieb:
> Hallo NG,
>
Sorry,
Da hat was mit dem Namen nicht funktioniert.
Lg


> Ich habe eine Kurze Frage.
>
> Ich lese unter anderem Dateien die 200 Mb Gross sind oder auch 500MB,
> die meisten sind aber kleiner. Vieleicht ist das auch eine Unglückliche
> Lösung die ich da habe.
>
> Wie kann ich eine Speicherproblematik bei Byte[] umgehen oder aussschalten?
>
> Ist vieleicht ein Stream besser, obwohl im Speicher die Abarbeitung
> flotter ist?
>
> Ich frage, weil ich nicht alles auf Stream umschreiben will, wenn es
> vieleicht eine Lösung mit Byte[] gibt.
>
> Hier der Source des Übeltäters
> (in abgewandelter Form im Internet zu finden)
>
> //dieses gibt es auch in umgekehrter Weise
> private byte[] StrToByteArray(string str)
> {
> Encoding enc = Encoding.Default;
> return enc.GetBytes(str);
> }
>


--
Liebe Gruesse Richie
http://bmss.homelinux.org/
Wenn du denkst, du denkst, dann denkst du nur du denkst, drum denke nie
gedacht zu haben, denn das Denken von Gedanken ist gedankenloses denken.

Hallo Richie,

"FakeAddress" <""bergo\"*nosp.at(FakeAddress)"> schrieb ...
> Ich lese unter anderem Dateien die 200 Mb Gross sind oder auch 500MB, die meisten sind aber kleiner. Vieleicht ist das auch eine
> Unglückliche Lösung die ich da habe.
>
> Wie kann ich eine Speicherproblematik bei Byte[] umgehen oder aussschalten?


Die Problematik kann man nicht. Arrays sind begrenzt auf den verfügbaren Speicher.

> Ist vieleicht ein Stream besser, obwohl im Speicher die Abarbeitung flotter ist?

Bei großen Dateien ist der Rückgriff auf einen FileStream oder eine
Inkarnation davon.

> Ich frage, weil ich nicht alles auf Stream umschreiben will, wenn es vieleicht eine Lösung mit Byte[] gibt.

Ob da eine Mischung von Array und Stream möglich/sinnvoll ist, hängt vom
jeweiligen Einsatzzweck ab. Durch eine aufgebohrten Stream könnte
man Teile der Datei im Speicher halten und die Zahl der Zugriffe
reduzieren, wenn mehrfach auf den gleichen Bereich gearbeitet wird.

Da müsstest Du aber konkreter werden.

> //dieses gibt es auch in umgekehrter Weise
> private byte[] StrToByteArray(string str)
> {
> Encoding enc = Encoding.Default;
> return enc.GetBytes(str);
> }

Wenn Du mit Bytes arbeitest, solltest Du direkt über einen FileStream
zugreifen und nicht erst eine Zeichenkette dazwischen schalten und konvertieren.
Das verschärft die Speicherproblematik nur, da auch die Zeichenkette
speicher abknappst.

Gruß Elmar

Elmar Boye schrieb:

Hallo Elmar,
Danke für Deine Info und Erklärung.

>
> Die Problematik kann man nicht. Arrays sind begrenzt auf den verfügbaren
> Speicher.
>

Das ist mir wohl bekannt, nur habe ich gehofft, dass es möglichkeiten
gibt eventuell die Speichernutzung zu Optimieren oder zu erweitern.

>
> Ob da eine Mischung von Array und Stream möglich/sinnvoll ist, hängt vom
> jeweiligen Einsatzzweck ab. Durch eine aufgebohrten Stream könnte
> man Teile der Datei im Speicher halten und die Zahl der Zugriffe
> reduzieren, wenn mehrfach auf den gleichen Bereich gearbeitet wird.
>
> Da müsstest Du aber konkreter werden.
>

Es ist relativ einfach erklärt.
Ich habe eine Maschinendatei welche mit Steuerzeichen HEX1E und HEX1D
begrenzt ist.
Dieser Programmteil ist dazu da, die Datei zu kontrollieren, ob alles
passt. Dies erfolgt mittels einfacher Layoutausgabe im Fenster. Mittels
Buttons kann man in der Datei navigieren.
Ein Button davon nennt sich "Rewrite", mit dem kann man fehlende
Features nachbessern (z.B.: Felder glätten oder Satznummerierung
einfügen, Codepage Ändern, usw.). Dann wird die Datei neu geschrieben.
Diese Korrekturen wollte ich in einem Array bewektstelligen, um
schneller zu sein. Eine Kontrolle soll ja nicht so lange dauern wie der
eigenliche Lauf.
Das wars gg

>> //dieses gibt es auch in umgekehrter Weise
>> private byte[] StrToByteArray(string str)
>> {
>> Encoding enc = Encoding.Default;
>> return enc.GetBytes(str);
>> }
>
> Wenn Du mit Bytes arbeitest, solltest Du direkt über einen FileStream
> zugreifen und nicht erst eine Zeichenkette dazwischen schalten und
> konvertieren.
> Das verschärft die Speicherproblematik nur, da auch die Zeichenkette
> speicher abknappst.
>

Im Normalfall, arbeite ich generell mit Streams.
Nur hat sich, warum auch immer der Gedanke manifestiert, dass ich Bytes
nehme, um effektiver zu werden. Ich habe mir gedacht, dass es mit Bytes
nicht sinnvoll ist so grosse Daten zu bearbeiten. Ich hatte gehofft C#
verwaltet den Speicher so damit das untergebracht werden kann.
Aber ich denke ich werde mir die Arbeit antun alles umzustellen, alleine
damit die Logik immer optimal läuft und keine bösen Überaschungen
passieren können.

Danke Dir nochmals

--
Liebe Gruesse Richie
http://bmss.homelinux.org/
Wenn du denkst, du denkst, dann denkst du nur du denkst, drum denke nie
gedacht zu haben, denn das Denken von Gedanken ist gedankenloses denken.

Hallo Richard


>> Arrays sind begrenzt auf den verfügbaren Speicher.
> Das ist mir wohl bekannt, nur habe ich gehofft, dass es möglichkeiten gibt
> eventuell die Speichernutzung zu Optimieren oder zu erweitern.


diese 'Optimierung' heisst heute allgemein:
64-Bit Windows + .NET.
(wobei selbst bei 64-Bit .NET oft 2GB Limits leider noch weiterhin gelten)

Auch eine (uva) Möglichkeit wäre manchmal:
'memory mapped files', ab .NET 4.0 auch im Framework drin (ansonst ggf
PInvoke).

Unter 32-Bit Windows/.NET
generell gelten Instanzen von ~500MB (oder mehr) als 'kritisch',
wegen default 2G/2G Splitting, Adressraum-Fragmentierung und div. anderen
Limiten.
(und recht abhängig von System/Windows-Konfiguration, sprich
'unvorhersehbar')
Dies oft selbst bei Vollausbau mit zB 4GB RAM.



--
Thomas Scheidegger - 'NETMaster'
http://dnetmaster.net/

Thomas Scheidegger schrieb:

Hi Thomas,

Sehr aufschlussreiche Information, danke.
Da ich in der Firma warscheinlich in den nächsten 10 Jahren keine 64Bit
Geräte bekommen werde, ist die Marschrichtung klar.
Sparen ... gg
Stream ist am sichersten, da ich mir Dateien im Extremfall von 1,5 Mio.
AdressSätzen arbeiten muss.
Das ist eine 450Mb grosse Datei, die natürlich mit andrerer Satzgröße
varrieren kann.
Aber dennoch habe ich hier mit Speicherverarbeitung den "Schlauch"
(keine Chance).

Ich Danke allen die mir Informationen geliefert haben.
Ich habe ja schon geschrieben, dass ich das umstellen werde, weil man ja
vorher nicht weis, wie der nächste Kunde drauf ist und was für Daten der
schickt ggg
Lg Richie
> Hallo Richard
>
>
>>> Arrays sind begrenzt auf den verfügbaren Speicher.
>> Das ist mir wohl bekannt, nur habe ich gehofft, dass es möglichkeiten
>> gibt eventuell die Speichernutzung zu Optimieren oder zu erweitern.
>
>
> diese 'Optimierung' heisst heute allgemein:
> 64-Bit Windows + .NET.
> (wobei selbst bei 64-Bit .NET oft 2GB Limits leider noch weiterhin
> gelten)
>
> Auch eine (uva) Möglichkeit wäre manchmal:
> 'memory mapped files', ab .NET 4.0 auch im Framework drin (ansonst
> ggf PInvoke).
>
> Unter 32-Bit Windows/.NET
> generell gelten Instanzen von ~500MB (oder mehr) als 'kritisch',
> wegen default 2G/2G Splitting, Adressraum-Fragmentierung und div.
> anderen Limiten.
> (und recht abhängig von System/Windows-Konfiguration, sprich
> 'unvorhersehbar')
> Dies oft selbst bei Vollausbau mit zB 4GB RAM.
>
>
>


--
Grüsse aus Tulln an der Donau

Es ist besser zu sagen was man meint, als nur zu meinen was man sagt.(ein gscheiter Mensch)
Lange Rede kurzer Sinn, versteht nicht jeder was man will. (war der noch gscheiter??)

Maurer Richard wrote:

> Da ich in der Firma warscheinlich in den nächsten 10 Jahren keine
> 64Bit Geräte bekommen werde, ist die Marschrichtung klar. Sparen ...

Jetzt echt? Nahezu alle Hardware aus den letzten Jahren ist 64-bit -
selbst das 3 Jahre alte Media Markt Notebook meiner Freundin ist
64-bit. Natürlich ist nur ein 32-bit OS installiert, aber das ist ja ab
Vista mehr ein Frage der Wahl und weniger ein Frage des Geldbeutels...

--
Immo Landwerth

Hallo Richard,
> Das ist eine 450Mb grosse Datei, die natürlich mit andrerer Satzgröße
> varrieren kann.
> Aber dennoch habe ich hier mit Speicherverarbeitung den "Schlauch"
> (keine Chance).

mit 2GB RAM kannst du vielleicht schon noch eine derart große Datei
komplett als Byte-Array im Hauptspeicher halten. Allerdings sollte dein
Programm so aufgebaut sein, dass dieses Array wirklich nur ein
einzigesmal existiert, und auch zwischendurch nicht kopiert wird. Also,
wenn ich mir deinen Code hier ansehe

>private byte[] StrToByteArray(string str)
>{
> Encoding enc = Encoding.Default;
> return enc.GetBytes(str);
>}


Wenn "StrToByteArray" ein Byte-Array mit 450 Mio Bytes zurückliefert,
dann waren im String str bereits 450 Mio Zeichen - und da String Unicode
(mit 2 Bytes pro Zeichen!) unterstützt, belegt dass dann rund 900Mio
Bytes zusätzlich, d.h. hier sind schon 1350 Mio Bytes verbraucht.
Solchen Code solltest du tunlichst vermeiden.

Grüße

- Michael -

Michael v. Fondern schrieb:

Hallo Michael,
> Also, wenn ich mir deinen Code hier ansehe
>
> >private byte[] StrToByteArray(string str)
> >{
> > Encoding enc = Encoding.Default;
> > return enc.GetBytes(str);
> >}
>
>
> Wenn "StrToByteArray" ein Byte-Array mit 450 Mio Bytes zurückliefert,
> dann waren im String str bereits 450 Mio Zeichen - und da String
> Unicode (mit 2 Bytes pro Zeichen!) unterstützt, belegt dass dann rund
> 900Mio Bytes zusätzlich, d.h. hier sind schon 1350 Mio Bytes
> verbraucht. Solchen Code solltest du tunlichst vermeiden.
>
Tja und wie Du recht hast .... gg
Ich habe mir eine Testdatei gemacht mit 1,2 Mio Sätzen zu 444 Zeichen. =
519MB, danach habe ich die Datei auf 500000 Sätze Reduziert.= 222MB.

Ich bin natürlich drauf gekommen, dass ich ja die eingelesenen
Filedaten (byte[] ByteList) in ein StringArray umwandle und daher
wiederum das Selbe an Mem benötige (Schwachsinn gg).
Danach habe ich gedacht ich ermittele alle Informationen aufgrund des
ByteArrays und NULLe es dann um wieder die Kapazität zu haben.
Tja, schmorrn. wieder OutOf Mem.
Ich habe gelesen, dass der Speicher erst im nächsten Umlauf. geleert
wird. *System.GC.Collect();* arbeitet so.

Ich kann auch mittels TextReader einlesen, aber da muss ich wieder die
Satzlänge wissen.
Die Datei ist immer eine Binäre mit Fixer Länge und Gruppen und Zeilen
Delimiter, also keine CrLf Datei.
Hier den Satz zu ermitteln war der Grund, dass ich auf die Byte[]
variante gekommen bin.

Jetz wäre es schön, wenn jemand eine effektive Logik kennt die genau das
macht. Im Moment steh ich auf der Leitung gg

Lg Richie

--
Grüsse aus Tulln an der Donau

Es ist besser zu sagen was man meint, als nur zu meinen was man sagt.(ein gscheiter Mensch)
Lange Rede kurzer Sinn, versteht nicht jeder was man will. (war der noch gscheiter??)

>> 900Mio Bytes zusätzlich, d.h. hier sind schon 1350 Mio Bytes verbraucht.
>> Solchen Code solltest du tunlichst vermeiden.
> Tja und wie Du recht hast ....

btw,
auch diverse .NET Methoden wie:
File.ReadAllText/ReadAllLines bzw StreamReader.ReadToEnd oä
scheinen 'unglücklich' gelöst und belegen temporär viel/vielfaches an
Speicher.

Mir wäre gerade keine 'safe' C# Methode bekannt,
eine grosse Textdatei (müsste dann UTF-16 sein)
_direkt_ 1:1 in einen .NET String (prinzipiell 'UTF-16')
einzulesen, ohne dass irgendwo dazwischen umkopiert/umcodiert wird
oder sonstige temporäre Instanzen entstehen
(bzw mehrfaches collection-/StringBuilder-resizing oä).
Möglich dass es mit 'unsafe' oder C++/CLI oder via native-interop einen
workaround gäbe.

Vielleicht könntest du auch eine Lösung finden,
die vom grossen Byte-array nur nach und nach kleinere 'Ausschnitte' nach
String wandelt,
aber dies wäre im Prinzip auch schon wieder relativ nahe an der klassischen
Stream-Lösung.
Eine Low-Level Lösung rein auf Byte-Array (raw Ascii-Codes) gänzlich ohne
..NET 'String'
ist natürlich prinzipiell auch stets möglich.


--
Thomas Scheidegger - 'NETMaster'
http://dnetmaster.net/