ab ca. 200MB: "Nicht genügend Zeichenfolgenspeicher"

[Dieter Strassner]

Hallo NG'ler,


mich beschäftigt schon wieder mal leidige Problem des endlichen Speichers...

In meiner Anwendung tritt nachwievor sporadisch in besonderen Situationen
der Fehler 14 "Nicht genügend Zeichenfolgenspeicher" auf.

Habe daraufhin mittels Testprogramm mit einer ConCat-Klasse

dies hier ablaufen lassen:

Set cc = New ConCat
For i = 1 To 1000000
cc.ConCat String(512, "x")
Next i

bei i=209122 (entspricht ca. 204 MB) steigt VB in der IDE aus (auch als
EXE)

Jetzt habe ich mal einen zusätzlichen String mit 10.000 zeichen (=20.000
Bytes) aufgenommen, jetzt steigt VB6 bereits bei i=69701 aus.
Nehme ich den String weider raus, bleibt es dennoch bei 69701 !? <ich
versteh es (noch) nicht.>


Dieses sonderbare Verhalten habe ich auch in der Anwendung: Eine bestimmte
Konstellation läuft prima ab, irgendwann später dann nicht mehr.
Die Daten sind augenscheinlich immer die gleichen, die Randbedingungen auch.

Am Hauptspeicher kann es hier auf meinem PC nicht liegen, der PC hat 3GB,
davon maximal 600MB in Benutzung (während die Fehlermeldung 14 angezeigt
wird).

VB6 verarbeitet bekanntlich bis zu 2 GB je Applikation. ich nehme mal an, da
zählt alles mit was zum Prozess gehört.

Bei einem Testprogramm kommt aus der Mini-exe und der VB-Runtime m.W. nach
nicht allzu viel dazu, was dann den großen rest von 1,8 GB-RAM auffressen
würde. zumal die Anwednung nie größer als ca. 210 MB wird.

Gibt es ncoh andere Beschränkungen?

Gibt es noch was "besseres" als eine ConCat-Klasse zur Stringverarbeitung zu
benutzen?
Hat jemand eine Idee wie ich den nutzbaren VB6-Stringspeicher "dauerhaft"
vergrößern kann (siehe wg. obiges Testverhalten).


Mit temporären ausladen auf Platte habe ich auch schon gedanklich
herumexpirmentiert, aber das die eigentlcihe Anwendung den String
schlußendlich wieder im Speicher benötigt wird (und dann auch noch nach WORD
transferieren muß), bin ich davon schnell wieder weg.

Alle unnötigen Klassen rechtzeitlich zerstören um Platz zugewinnen habe ich
wchon umgesetzt, dto. mit ADODb:Recordsets und Arrays.

--
Viele Grüße - Dieter

EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz

[Martin KoWi]

Hallo,

die Grenze für Strings dürfte wohl eher in der Nähe von 256MB liegen!

Um evtl. Fehler in der ConCat-Klasse auszuschließen kannst du es einfach
mal mit einen einzigen String versuchen:

S = String(200& * 1024& * 1024&, "x")

hier ist bei mir schon bei ca. 200 schluss!
und das ist noch nicht mal ein halbes GB.

irgendwo hatte ich (glaube ich) noch einen anderen Stringbuilder, der
anders Speicher alloziert hat, und deutlich mehr konnte - bin aber nicht
sicher und muss erst suchen.

gruß, martin.

[W. Wolf]

Am 03.11.2011 13:37, schrieb Martin KoWi:
> Hallo,
>
> die Grenze für Strings dürfte wohl eher in der Nähe von 256MB liegen!
>

stimmt nicht ganz, Len("x") = 1 aber LenB("x") = 2

Folgendes kommt bei mir raus:
Dim tests As String
tests = String(244& * 1024& * 1024&, "x")
Debug.Print LenB(tests)
End Sub

das funktioniert noch, Ergebnis 511705088, also irgendwo bei 500MB.


Habe viel mit Concats getestet und bin letzten Endes doch bei Join
geblieben. Der Gewinn bei meinen (wesentlich kleineren) Concats ist,
trotz diversen Tricks, nur marginal. Das hier funktioniert bei mir
(VB6-IDE WIN7-64) bestens:

Private Sub Form_Click()
Dim test() As String
Dim tests As String
ReDim test(500000)
Dim i As Long
For i = 0 To UBound(test)
test(i) = String(512, "x")
Next i
tests = Join(test)
Debug.Print LenB(tests)
End Sub
Debug-Ergebnis: 513001024

Schönen Gruß
W. Wolf

[Dieter Strassner]

Hallo W.,

>> die Grenze für Strings dürfte wohl eher in der Nähe von 256MB liegen!
>>
>
> stimmt nicht ganz, Len("x") = 1 aber LenB("x") = 2
>
> Folgendes kommt bei mir raus:
> Dim tests As String
> tests = String(244& * 1024& * 1024&, "x")
> Debug.Print LenB(tests)
> End Sub
>
> das funktioniert noch, Ergebnis 511705088, also irgendwo bei 500MB.

Da komm ich unter Win-XP(32) nur auf ca. 90 MB

> Habe viel mit Concats getestet und bin letzten Endes doch bei Join
> geblieben. Der Gewinn bei meinen (wesentlich kleineren) Concats ist,
> trotz diversen Tricks, nur marginal. Das hier funktioniert bei mir
> (VB6-IDE WIN7-64) bestens:

Deine Lösung klingt auch interessant. da die Anzahl der Concat.ADD
überschaubar sind, werde ich mal versuchsweise einen Umbau vornehmen!

> Private Sub Form_Click()
> Dim test() As String
> Dim tests As String
> ReDim test(500000)
> Dim i As Long
> For i = 0 To UBound(test)
> test(i) = String(512, "x")
> Next i
> tests = Join(test)
> Debug.Print LenB(tests)
> End Sub
> Debug-Ergebnis: 513001024

Auf meinem PC läuft die Schleife erfolgreich durch (sogar recht flott), aber
bei der Zuweisung nach "tests" kommt Error 14,

da jetzt ja sogar der doppelte Speicher benötigt werden würde!
Und das funktioniert auf deinem PC?? <ungläubig staun>

[Dieter Strassner]

... und das merkwürdige für mich ist dann auch noch:

> Auf meinem PC läuft die Schleife erfolgreich durch (sogar recht
> flott), aber bei der Zuweisung nach "tests" kommt Error 14,
>
> da jetzt ja sogar der doppelte Speicher benötigt werden würde!
> Und das funktioniert auf deinem PC?? <ungläubig staun>

wenn ich das Array halbiere, klappt die Zuweisung auch nicht! :-(
Obwohl es nun rein rechnerisch reichen müßte.

[W. Wolf]

"Dieter Strassner" <spam...@strassner.biz> schrieb

>
> Da komm ich unter Win-XP(32) nur auf ca. 90 MB
>

Ok, sitze nun auch vor einem XP. Das läuft hier noch:

Private Sub Form_Click()
Dim test() As String
Dim tests As String

ReDim test(266000)

Dim i As Long
For i = 0 To UBound(test)
test(i) = String(512, "x")
Next i
tests = Join(test)
Debug.Print LenB(tests)
End Sub

Ergebnis 272917024, irgendwo knapp danach ist hier auch Schluß.
Staune nun selber ein bischen. Offensichtlich gibt es spürbare
Unterschiede zu W7 oder zu den 64 Bit.

Brauchst Du das ganze Zeugs in einem String? Deine Schleife mit
intern gleichem Inhalt scheint ja zu funktionieren. Kannst Du die
Aufgabe nicht irgendwie fragmentieren?

Schönen Gruß
W. Wolf

[Martin KoWi]

Am 03.11.2011 17:13, schrieb W. Wolf:

> stimmt nicht ganz, Len("x") = 1 aber LenB("x") = 2

hast natürlich recht, darunter schrieb ich eh noch (korrekter):

> und das ist noch nicht mal ein halbes GB.

Aber da du Win764 erwähnt hast, hab ich das dort auch noch probiert.
Und da gelingt es kompiliert schon ziemlich nahe ans Limit zu kommen:

782& * 1024& * 1024& ergibt ca. 1,6 GB RAM (also String mit knapp 800
Mio Chars)
Beweisfoto ;-) http://dl.dropbox.com/u/13706303/RAM-Taskman.png

Das gelingt aber auch nicht immer, manchmal geht auch nur ca. 600.
Je nachdem wie das System aufgelegt ist, ist auch schon viel früher
Schluss - denn das RAM muss als _kontinuierlicher_ Block frei sein.
Außerdem ist das nätürlich ein nutzloses Testprog, das sonst nichts tut.

Ich denke auf Kundensystemen muss man viel früher mit Problemen rechnen
und sollte evtl. Alternativen überdenken. Also zb. direkt an der Datei
arbeiten - geht das nicht?

gruß, martin.

[Dieter Strassner]

Hallo Martin,

vielen Dank für deine Ausführungen!

> Aber da du Win764 erwähnt hast, hab ich das dort auch noch probiert.
> Und da gelingt es kompiliert schon ziemlich nahe ans Limit zu kommen:
>
> 782& * 1024& * 1024& ergibt ca. 1,6 GB RAM (also String mit knapp 800 Mio
> Chars)
> Beweisfoto ;-) http://dl.dropbox.com/u/13706303/RAM-Taskman.png
>
> Das gelingt aber auch nicht immer, manchmal geht auch nur ca. 600.
> Je nachdem wie das System aufgelegt ist, ist auch schon viel früher
> Schluss - denn das RAM muss als _kontinuierlicher_ Block frei sein.
> Außerdem ist das nätürlich ein nutzloses Testprog, das sonst nichts tut.

Das VB unter W7 ein anderes Verhalten bzgl. des Speichermanagement zeigt,
hätte ich nicht vermutet.
Aber insgesamt ist das ja sehr positiv.

> Ich denke auf Kundensystemen muss man viel früher mit Problemen rechnen
> und sollte evtl. Alternativen überdenken. Also zb. direkt an der Datei
> arbeiten - geht das nicht?

Zum ersten Satz: Ja klar, deshlab ja mein Thread.
Zur Frage: Benötige einen kompletten String um diesen an WORD zu geben.
Spätestens bei der Übergabe würde es dann krachen :-(

Werde aber zum einen den JOIN() als Alternative zur CONCAT-Klasse testen,
zum anderen mal sehen ob ich nicht doch eine Chance habe, die Daten
scheibchenweise an WORD zu geben.

[Dieter Strassner]

hallo W.,

>> Da komm ich unter Win-XP(32) nur auf ca. 90 MB
>>
> Ok, sitze nun auch vor einem XP. Das läuft hier noch:
>
> Private Sub Form_Click()
> Dim test() As String
> Dim tests As String
> ReDim test(266000)
> Dim i As Long
> For i = 0 To UBound(test)
> test(i) = String(512, "x")
> Next i
> tests = Join(test)
> Debug.Print LenB(tests)
> End Sub
>
> Ergebnis 272917024, irgendwo knapp danach ist hier auch Schluß.
> Staune nun selber ein bischen. Offensichtlich gibt es spürbare
> Unterschiede zu W7 oder zu den 64 Bit.

Siehe auch Positing von Martin, ja da scheint es wohl gewaltige Unterscheide
zu geben.

> Brauchst Du das ganze Zeugs in einem String? Deine Schleife mit
> intern gleichem Inhalt scheint ja zu funktionieren. Kannst Du die
> Aufgabe nicht irgendwie fragmentieren?

Das ist auch mein Ansatz mittlerweile. Ob und wie weiß ich noch nicht, aber
testen werde ich es wohl müssen....

Vielen Dank für Deine Hilfe!

[Martin KoWi]

Am 03.11.2011 19:36, schrieb Dieter Strassner:

> Das VB unter W7 ein anderes Verhalten bzgl. des Speichermanagement
> zeigt, hätte ich nicht vermutet.

Das würde ich etwas anders formulieren.
Nicht VB zeigt ein anderes Verhalten sondern das OS!

Ich habe noch verschiedene StringBuilder-Classen probiert -
und letztlich mündet es doch immer (zumindest irgendwo unter der Haube)
in einer Variante von SysAllocString o.ä. VB macht da nichts anderes.
Ich glaube diese Grenzen zeigen sich bei allen 32bit Prozessen ähnlich.
Und beim googeln sind mir auch ganz ähnliche Fragen/Ergebnisse zb. auch
von 32bit .Net Programmen untergekommen.

> Zur Frage: Benötige einen kompletten String um diesen an WORD zu geben.

Jetzt würde ich aber schon hinterfragen, warum das so sein muss.
Was machst du da genau? Vielleicht kannst du dein Szenario genauer
beschreiben?

> Spätestens bei der Übergabe würde es dann krachen :-(

Naja, vielleicht kann man es eben _ganz_ anders machen...

gruß, martin.

[Martin KoWi]

interessanter Artikel zum Thema:

http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

drum bleibt einem 32bit Process unter x64 wesentlich mehr übrig!

gruß, martin.

[Thorsten Albers]

Dieter Strassner <spam...@strassner.biz> schrieb im Beitrag
<j8ts60$vij$1...@news.albasani.net>...

> Am Hauptspeicher kann es hier auf meinem PC nicht liegen, der PC hat 3GB,

> davon maximal 600MB in Benutzung (während die Fehlermeldung 14 angezeigt
> wird).

Das Problem dürfte weniger dadurch verursacht sein, daß nicht genügend
Speicher zur Verfügung steht, sondern daß nicht genügend
_zusammenhängender_ Speicher zur Verfügung steht. Wenn es unter dem einen
OS früher auftritt als unter dem anderen, dürfte das daraufhindeuten, daß
das andere OS eine effizientere Speicherverwaltung verwendet.
Für Fragmentierung gibt es jede Menge Ursachen; das fängt dort an, wo das
OS verwendete DLLs etc. in den Speicher des Prozesses mappt; und es hört
nicht bei der simplen Zusammensetzung von Strings in VB auf, denn Du mußt
bedenken, daß VB für jeden String nicht nur den eigentlichen
String-Speicher allozieren muß sondern auch noch Speicher für den
String-Pointer (String = Pointer auf Pointer auf String); letzteres
benötigt zwar nicht viel Speicher, aber jeder allozierte Speicher kann
verhindern, daß Speicher fragmentiert wird.

Das Hauptproblem ist natürlich, daß der allozierte Speicher bei der
Zuweisung von Strings unter VB auch mit SysReAllocString() erst freigegeben
wird, _nachdem_ der neue Speicher alloziert wurde.

Eine mögliche Problemlösung wäre, in Deiner Klasse eine eigene
String-Speicherverwaltung mit LocalAlloc(), LocalReAlloc() etc. aufzubauen.
LocalReAlloc() wie auch GlobalReAlloc() versuchen m.W. erst, den bereits
allozierten Speicher zu erweitern; nur, wenn das fehlschlägt, wird neuer
Speicher alloziert und der alte Speicherinhalt umkopiert - was auch für die
Performance interessant wäre.

Eine andere übliche Methode ist, den String nicht bei jeder Änderung neu
zusammenzusetzen sondern mit voralloziertem Speicher zu arbeiten, d.h. es
wird seltener neu alloziert, dafür aber mehr Speicher am Stück, wodurch die
Fragmentierung - je nach Größe des vorallozierten Speichers - erheblich
sinken und die Geschwindigkeit deutlich steigen kann. Deine Klasse muß dann
natürlich eine zusätzliche String-Längenangabe verwalten. Schematisches
Beispiel ('on-the-fly'):

Const ALLOCSIZE As Long = ...

sClassMem = String$(ALLOCSIZE, vbNullChar)
lClassMemUsed = 0

...
lLen = Len(sStringToAdd)
If (lClassMemUsed + lLen) > Len(sClassMem) Then
lCount = lLen - (Len(sClassMem) - lClassMemUsed)
If lCount < ALLOCSIZE Then lCount = ALLOCSIZE
sClassMem = sClassMem & String$(lCount, vbNullChar)
' **
End If

Mid$(sClassMem, lClassMemUsed + 1) = sStringToAdd
lClassMemUsed = lClassMemUsed + lLen


Mid$() = <String> hat dabei den häufig übersehenen Vorteil, daß _kein_
neuer Speicher alloziert sondern <String> in den bereits allozierte kopiert
wird.

An der mit '**' bezeichneten Stelle kann man dann noch einen zusätzlichen
Schutz einbauen:
Tritt hier einer der 'Out of memory'-Fehler auf, schreibt man den gesamten
String in eine temporäre Datei (dann natürlich mit Windows API-Methoden),
löscht den _gesamten_ Klassen-Speicher (und räumt möglw. auch sonst noch
auf), alloziert ihn neu in der erforderlichen Größe (+ Zusatz) und liest
den String wieder ein. Kommt es auch dabei zu einem der 'Out of
memory'-Fehler, muß man sich eine andere Strategie überlegen...

Sollte sich das Problem so nicht lösen lassen, wäre vielleicht DDE eine
Lösung, um den String in Word zu übertragen. Auch eine Übergabe über die
Zwischenablage könnte eine Lösung sein.

--
Thorsten Albers

gudea at gmx.de

[Dieter Strassner]

Hallo Martin,

> interessanter Artikel zum Thema:
>
> http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
>
> drum bleibt einem 32bit Process unter x64 wesentlich mehr übrig!

Ja, in der Tat, sehr interessant.
Danke!

[Dieter Strassner]

Hallo Martin,

>> Das VB unter W7 ein anderes Verhalten bzgl. des Speichermanagement
>> zeigt, hätte ich nicht vermutet.
>
> Das würde ich etwas anders formulieren.
> Nicht VB zeigt ein anderes Verhalten sondern das OS!

Da hast Du wohl recht.

> Ich habe noch verschiedene StringBuilder-Classen probiert -
> und letztlich mündet es doch immer (zumindest irgendwo unter der
> Haube) in einer Variante von SysAllocString o.ä. VB macht da nichts
> anderes. Ich glaube diese Grenzen zeigen sich bei allen 32bit
> Prozessen ähnlich. Und beim googeln sind mir auch ganz ähnliche
> Fragen/Ergebnisse zb. auch von 32bit .Net Programmen untergekommen.
>
>> Zur Frage: Benötige einen kompletten String um diesen an WORD zu
>> geben.
>
> Jetzt würde ich aber schon hinterfragen, warum das so sein muss.
> Was machst du da genau? Vielleicht kannst du dein Szenario genauer
> beschreiben?
>
>> Spätestens bei der Übergabe würde es dann krachen :-(
>
> Naja, vielleicht kann man es eben _ganz_ anders machen...

Ja, da bin ich am überlegen. Bei der Konzeption war damals eine gute
Perfomance das Hauptkriterium.
Nachdem die Maschinen die letzten jahre schneller wurden, läßt sich ja auch
mal ein gang zurückschalten.
Werde also mal ausprobieren die Daten scheibchenweise an WORD zu geben.

[Dieter Strassner]

Hallo Thorsten,

>> Am Hauptspeicher kann es hier auf meinem PC nicht liegen, der PC hat
>> 3GB,
>
>> davon maximal 600MB in Benutzung (während die Fehlermeldung 14
>> angezeigt wird).
>
> Das Problem dürfte weniger dadurch verursacht sein, daß nicht genügend
> Speicher zur Verfügung steht, sondern daß nicht genügend
> _zusammenhängender_ Speicher zur Verfügung steht. Wenn es unter dem
> einen OS früher auftritt als unter dem anderen, dürfte das
> daraufhindeuten, daß das andere OS eine effizientere
> Speicherverwaltung verwendet.

Ja, siehe Link von Martin.

> Für Fragmentierung gibt es jede Menge Ursachen; das fängt dort an, wo
> das OS verwendete DLLs etc. in den Speicher des Prozesses mappt; und
> es hört nicht bei der simplen Zusammensetzung von Strings in VB auf,
> denn Du mußt bedenken, daß VB für jeden String nicht nur den
> eigentlichen String-Speicher allozieren muß sondern auch noch
> Speicher für den String-Pointer (String = Pointer auf Pointer auf
> String); letzteres benötigt zwar nicht viel Speicher, aber jeder
> allozierte Speicher kann verhindern, daß Speicher fragmentiert wird.
>
> Das Hauptproblem ist natürlich, daß der allozierte Speicher bei der
> Zuweisung von Strings unter VB auch mit SysReAllocString() erst
> freigegeben wird, _nachdem_ der neue Speicher alloziert wurde.

Ich hab mir jetzt nochmal die verwendete ConCat-Klasse angeschaut. Und ja,
´genau das ist auch die Schwachstelle.
Es werden zwar aus dem Stand 1 MB reserviert, aber sobald mehr als 1 MB
angefordert werden, wird zwangsweise umgeschoben.

Da werde ich mich mal dran versuchen.

Meine Idee dazu: Erst ermitteln was als Maxmum an zusammenhängenden
Speicher möglich ist.
Diesen reservieren (evtl. etwas "übrig lassen"), dann füllen. Wenn voll dann
Fehler, bzw.Alternativstrategie.

> Sollte sich das Problem so nicht lösen lassen, wäre vielleicht DDE
> eine Lösung, um den String in Word zu übertragen. Auch eine Übergabe
> über die Zwischenablage könnte eine Lösung sein.

ja, aber oben beschriebenenes Szenario werde ich vorher ausprobieren.
Die Alternative wäre die Daten scheibchenweise an WORD zu geben.

Vielen Dank! Werde also mal nach "LocalAlloc(), LocalReAlloc() " & Co
googeln....

[W. Wolf]

Am 04.11.2011 07:49, schrieb Dieter Strassner:
[...]

>
> Da werde ich mich mal dran versuchen.
>
> Meine Idee dazu: Erst ermitteln was als Maxmum an zusammenhängenden
> Speicher möglich ist.
> Diesen reservieren (evtl. etwas "übrig lassen"), dann füllen. Wenn voll
> dann Fehler, bzw.Alternativstrategie.
>

Dann schau dir mal das hier (VB-Projekt 8KB) an:
www.ww-a.de/download/concattest.zip

Das sind eigene Versuche mit unterschiedlichen Concat-Strategien und
Zeit-Auswertung. War alles nur für den eigenen Gebrauch gedacht, daher
alles andere als sauber. Immerhin sparst Du dir etwas Arbeit, wenn Du
eigene Vergleiche machen willst. Sollte dabei auch noch eine
Pattern-Lösung dabei raus kommen, würde ich mich (wir uns) über einen
Bericht freuen ;-)

Schönen Gruß
W. Wolf

[Heinz-Mario Frühbeis]

Ich bin mir nicht sicher, ob ich das alles "richtig" gelesen habe, also auch
verstanden habe:

Ich denke, es soll ein Worddokument werden/sein

Soll werden:
So ein Word-Dokument (als VB-Objekt) hat doch bestimmt ein Text-Property
(oder so was) ... da läßt sich doch bestimmt was appenden

Ist schon:
Dann kann man doch vlt. die Datei binär aufsplitten und wieder
zusammensetzen

Nur ein Gedanke ...

[Dieter Strassner]

Hallo W.,

> Dann schau dir mal das hier (VB-Projekt 8KB) an:
> www.ww-a.de/download/concattest.zip
>
> Das sind eigene Versuche mit unterschiedlichen Concat-Strategien und
> Zeit-Auswertung. War alles nur für den eigenen Gebrauch gedacht, daher
> alles andere als sauber. Immerhin sparst Du dir etwas Arbeit, wenn Du
> eigene Vergleiche machen willst. Sollte dabei auch noch eine
> Pattern-Lösung dabei raus kommen, würde ich mich (wir uns) über einen
> Bericht freuen ;-)

Vorab schon mal:
Mittels clsDynArray konnten 1,97 GB allokiert werden, Recordverdächtig!
(Win-XP,32Bit, 3GB-RAM, davon 398 MB benutzt, läuft unter vmware 7)

Was da leider noch nicht klappt, ist nur die Hälfte zu benutzen und dies
andere Hälfte für die Stringzuweisung nach WORD zu nutzen.
Aber ich bleibt dran....

[Dieter Strassner]

hallo Heinz-Mario,

> Ich denke, es soll ein Worddokument werden/sein
>
> Soll werden:
> So ein Word-Dokument (als VB-Objekt) hat doch bestimmt ein
> Text-Property (oder so was) ... da läßt sich doch bestimmt was
> appenden

Ja geht vermutlich. hatte ich halt in der Vergangheit nicht gemacht, weil
"schnarch langsam" :-(
... im Verhältnis zu einer schnellen ConCat-Klasse.

[Thorsten Albers]

Dieter Strassner <spam...@strassner.biz> schrieb im Beitrag

<j901um$1vp$1...@news.albasani.net>...

> Meine Idee dazu: Erst ermitteln was als Maxmum an zusammenhängenden
> Speicher möglich ist.
> Diesen reservieren (evtl. etwas "übrig lassen"), dann füllen. Wenn voll
dann
> Fehler, bzw.Alternativstrategie.

Das ist natürlich der Idealfall, wenn man weiß, wieviel Speicher maximal
verbraucht werden kann.

> ja, aber oben beschriebenenes Szenario werde ich vorher ausprobieren.
> Die Alternative wäre die Daten scheibchenweise an WORD zu geben.

...oder aus VB heraus ein Word-Dokument zu erzeugen und dann das
Word-Dokument an Word zu übergeben? Dafür wäre vermutlich einiges an
Recherche-Arbeit über entsprechende Bibliotheken bzw. das Word-Datei-Format
notwendig.
Als einfache Alternative bei der Übergabe einer ganzen Datei steht
natürlich immer RTF zur Verfügung, wofür es dann auch nicht notwendig wäre,
derart viel String-Daten im Speicher zu halten.

> Vielen Dank! Werde also mal nach "LocalAlloc(), LocalReAlloc() " & Co
> googeln....

Wenn es um mehr als etwas Privates und Einmaliges geht, wäre es
überlegenswert, sich gleich eine komplette String-Klasse zu schreiben, die
für alle String-Funktionen effektiver arbeitet als die VB-Funktionen.

[Heinz-Mario Frühbeis]

Hallo Dieter!

"Dieter Strassner"...

> hallo Heinz-Mario,
>
>> Ich denke, es soll ein Worddokument werden/sein
>>
>> Soll werden:
>> So ein Word-Dokument (als VB-Objekt) hat doch bestimmt ein
>> Text-Property (oder so was) ... da läßt sich doch bestimmt was
>> appenden
>
> Ja geht vermutlich. hatte ich halt in der Vergangheit nicht gemacht, weil
> "schnarch langsam" :-(
> ... im Verhältnis zu einer schnellen ConCat-Klasse.

"Schnarch langsam" ... _ohne_ Error :)
Immer diese Entscheidungen; ... da wünscht man sich doch bestimmt
entsprechende Schnittstellen am Objekt.

Mit Gruß
Heinz-Mario Frühbeis

[W. Wolf]

Am 04.11.2011 13:18, schrieb Dieter Strassner:
[...]

>
> Vorab schon mal:
> Mittels clsDynArray konnten 1,97 GB allokiert werden, Recordverdächtig!
> (Win-XP,32Bit, 3GB-RAM, davon 398 MB benutzt, läuft unter vmware 7)
>
> Was da leider noch nicht klappt, ist nur die Hälfte zu benutzen und dies
> andere Hälfte für die Stringzuweisung nach WORD zu nutzen.
> Aber ich bleibt dran....
>

Der Klasse könntest Du statt Strings StrConvert-Byte-Arrays übergeben
und per API in das klasseninterne Array einfügen. Wenn Du keinen
Unicode benötigst, könntest Du damit schon die Hälfte des Speichers
sparen. Aus dem Array kannst Du optimale Fragmente extrahieren und diese
Word übergeben.

Schönen Gruß
W. Wolf