Hallo,
das von mir unter [Beta] FastGraphicsLib 1.0.0.5
beschriebene Programm hat eine Schleife, in der aus einer Liste von Bildern die Grösse (.size) überprüft wird. Bilder mit richtiger Grösse werden dann in eine weitere Liste übernommen. Leider finde ich nicht die richtige Methode zum auslesen. Ab 50 Bildern (8 megapixel) ist Schluss, mache ich ein build für 64 bit gehts noch etwas weiter...

im Bild: etwas über 3 GB ram...und Schluss. Zu dumm, das das Programm am Ende auf x86 laufen soll

Die schuldige Schleife ist die hier:

..und wenn die losläuft um 50 Bilder zu prüfen füllt sich der Ram kontinuierlich:

Sicher kann man die Grösse auch aus dem jpg Header auslesen, aber das überfordert mich als Anfänger komplett (nach 4h aufgegeben). Ausserdem müsste ich das dann für alle Fromate machen - was für ein Aufwand. Ich verstehe einfach nicht warum der ram nach dem auslesen der Bildgrösse mittels Image.FromFile(Dateiliste(i)).Size zuwuchert. Mir schwant das ich irgendwas wichtiges weggelassen hab (.dispose hat nix genutzt). Für Hinweise oder Vorschläge wie das besser geht bin ich dankbar.
Gruss, emil

Mach das mit Using!

timmi31061 schrieb:

Mach das mit Using!

Wow! Das ging schnell! Besten Dank Timmi das ist es Die Ramkurve bleibt hübsch glatt.
Using ist mir noch gänzlich unbekannt, werd ich gleich mal erkunden.

Using heißt nur, dass am Ende des Using-Blocks Dispose aufgerufen wird -> deshalb funktioniert using auch nur wenn der Typ des Objektes IDisposable implementiert.
Kurz um: Der Code ist nichts anderes als dies:

timmi31061 schrieb:

VB.NET-Quellcode

1. ReDim Preserve Liste(ind)

Das ist Crap, mach da eine New List(Of ...) draus!

RodFromGermany schrieb:

Das ist Crap, mach da eine New List(Of ...) draus

Ok, wieder was gelernt, habs jetzt so:

In der Hoffnung das es nicht nur zufällig funktioniert und .Length eines String() das gleiche ist wie .Count einer Liste.
Danke nochmal, Gruss, emil

Wenn es nicht ur um Geschwindigkeit geht, kannst du auch Lambda benutzen, kannste ja auch googeln :).

@emil.quast
Und an deiner Stelle würde ich eine ForEach benutzen, die ist schneller und meiner Meinung nach übersichtlicher, weil man die nervige Zählervariable nicht hat.

@LaMiy
Also Fro Each müsste eigentlich langsamer sein.Bei For i wird einfach nur über einen Arrayindex direkt auf den Speicher zugegriffen, bei For Each wird bei jeder Iteration Enumerator.MoveNext und Enumerator.Current aufgerufen. Ich glaube aber nicht, dass der Unterschied Einfluss auf das Programm hat.

Also ich habe mitbekommen, dass ForEach schneller sein soll.
Hier vielleicht auch mal eine interessante Diskussion. stackoverflow.com/questions/36…uns-faster-for-or-foreach

Wenn du dich ein bisschen mit C++ auskennst wird ganz klar deutlich, warum For schneller sein muss. In .Net ist ein Array etwas abstraktes, eben eine Klasse. Im lowlevel gesehen ist ein Array aber nichts anderes, als ein Pointer. Laut der Pointeraritmethik wird die Adresse eines Pointers bei + und - immer um die Größe der darin gespeicherten Objekte verändert. Wenn du also einen Pointer auf einen Integer hast und +1 rechnest, dann erhöht sich die Adresse um 4 Bytes. Das ist im Prinzip genau das, was ein Array macht. Es wird die Startadresse gespeichert und dann immer um die gewünschte Anzahl Objekte erhöht. In C++ könnte man also *(p+1) schreiben, um das zweite Objekt eines Arrays anzusprechen. Da das aber sehr unbequem ist, hat man die Klammer-Schreibweise erfunden. Demnach ist p[1] absolut identisch zu der vorherigen Lösung. Und wenn man jetzt betrachtet, dass Pointerzugriff die schnellste Möglichkeit ist, an einem Computer auf Speicher zuzugreifen, dann ist auch klar, dass die For-Schleife schneller ist. Die Inkrementierung von i wird auch meist direkt in den Registern durchgeführt, was nochmals Performance geben sollte.

Übrigens ist Using nicht nur sowas:

sondern sowas:
(Wobei die Resource-Variable natürlich nach dem Using-Block nicht mehr verfügbar ist.)
Dadurch wird sichergestellt, dass auch im Falle einer auftretenden Exception die Ressource trotzdem verworfen wird.