[VB.NET] geheugenlek opsporen en vernietigen

[Damic]

Mijn vraag:
in het programma Telemeter-Indicator.net zit ik al een geruime tijd met een geheugen lek en sinds de laatste toevoeging van sqlite db en het meer multi threaded maken is het helemaal niet leuk meer. Elke update komt er ongeveer 2MB bij (update is instelbaar van 10 tot 60 minuten wachten).

Relevante software en hardware die ik gebruik:
VB.net in VS17 Community
Windows 10
R7 1700x
...

Wat ik al gevonden of geprobeerd heb:
Ik heb al bezig geweest met dotMemory en de Memory Analyzer dat in VS zit maar word er niet echt wijzer uit. Wel zien ik 1 functie altijd terug komen en dat is Http_Request() eigen geschreven functie die eigenlijk de url opzoekt en terug geeft, maar ja die word ook wel een paar keer aangeroepen.

Code van http_request() kan je hier vinden: http://www.codedump.be/code/1491/ eventueel kan ik de laatste beta code ook online gooien.

[Camulos]

Als ik naar de code kijk van je http_request() methode.. dan zie ik dat je postReq variabele in met een with-statement gebruikt wordt ipv een using

Het is mogelijk dat het niet correct gedisposed wordt.

Daarnaast geeft StackOverflow nog de tip om eens GC.Collect() te gebruiken aan het einde van de methode aangezien request/response behoorlijk wat alloceerd.

Algemene tip: Je code is zeer procedureel geschreven, en zou mogelijk makkelijker te begrijpen zijn als je deze methode opknipt, al is het maar vanwege de grote indenting

[Damic]

gc.collect doen ik aan het einde van alles, dat helpt, maar als er toch nog ergens iets vast zit doet het natuurlijk niet

HttpWebRequest heeft geen iDispolsable daarmee dat ik geen using gebruik.

[AtleX]

Een GC..Collect() is eigenlijk nooit aan te raden. Je kan er ongewild objecten mee promoveren naar de volgende generaties waardoor je misschien inderdaad een oplopend geheugengebruik ziet, tot er een collectie van Gen2 plaatsvind en eventueel een heap compaction om holes te dichten.

In de Memory Analyzer van VS2017 kan je trouwens snapshots maken die je kan vergelijken. Misschien is het een idee om van elke run van deze code een snapshot te maken? Dan kan je na drie of vier runs de snapshots vergelijken en dan zie je misschien wel waar je geheugen blijft.

Weet je ook heel zeker dat je echt een lek hebt? Best kans dat je na een tijdje draaien, en dus een aantal runs voor de updates, gewoon een drop in gebruik hebt door een collectie van Gen2. Dat zie je in de memory analyzer terug als zo'n zaagtandprofiel.

[ Voor 20% gewijzigd door AtleX op 25-05-2017 16:38 ]

[Damic]

Ha eens proberen zonder gc.collect()

Ja die snapshot heb ik al, maar ik word er niet wijzer van.

[cannibal]

Je maakt dan 2 snapshots, 1 voor de aanroep en 1 na de aanroep, deze kun je dan vergelijken.

Dit kon zo iig bij de memory analyzer van Jetbrains, hier heb ik iig wel eens ooit een lek mee gevonden (een debug = true op een xslt translator, waardoor er intermediate results in de temp-directory gezet werden en de translator uiteindelijk niet opgeruimd )

[mathias82]

Ik ken geen VB.NET, maar moet je de streams waar je gebruik van maakt niet closen na gebruik?

[Damic]

@cannibal ja ik heb 2 snapshot maar word er niet wijzer uit. Ik zal eens kijken of dat ik screenshots kan plaatsen.

@mathias82 al de streams die ik aanroep via using worden ook automatisch afgesloten.

Die collect is niet het probleem, er zijn nu 6 updates voorbij gegaan en geheugen is van 16MB naar 37MB gegaan. Dat is 3.5MB per update terwijl het ervoor maar max. 2MB was

[ Voor 8% gewijzigd door Damic op 25-05-2017 22:48 ]

[whoami]

Hoe meet je dat geheugenverbruik ?

@cannibal ja ik heb 2 snapshot maar word er niet wijzer uit. Ik zal eens kijken of dat ik screenshots kan plaatsen.

uit die code geraak ik eigenlijk ook niet wijs hoor. Hoog tijd om te refactoren!
Waarom denk je dat het probleem zich in die method bevind ?

[ Voor 85% gewijzigd door whoami op 25-05-2017 22:49 ]

[Damic]

Refactoren is niet nodig, ik kan het lezen en als ik stop dan stop ik ermee. Ik lees het geheugen gebruik uit via taskmanager, ok is niet de echt goede manier maar het geeft wel een goede indicatie van of het wel snor zit met je programma.

Heb hier nog een programma draaien van me en dat blijft mooi op 8MB staan.

Waarom denk ik dat het in die functie zit: als ik dotMemory draai of dat memory ding van VS dan komt die functie het meeste naar boven.

[ Voor 17% gewijzigd door Damic op 25-05-2017 22:53 ]

[whoami]

Damic schreef op donderdag 25 mei 2017 @ 22:52:
Refactoren is niet nodig, ik kan het lezen en als ik stop dan stop ik ermee.

Euh .... 'k Weet niet , maar blijkbaar kan je het zo goed lezen dat je momenteel ook niet ziet waar jouw memleak zit

Ik zie ook dat je af en toe van de ene stream leest en die gegevens naar een andere strem schrijft. Waarom gebruik je daar niet CopyTo / CopyToAsync ?

[ Voor 18% gewijzigd door whoami op 25-05-2017 22:58 ]

[johnkeates]

Stel dat je het in een andere taal of een ander framework namaakt, gaat het dan beter?

[Damic]

@whoami ik kan het wel lezen, maar de bug kan best ergens in een verkeerde declaratie zitten ofzo
@johnkeates Ik kan geen andere taal behalve php en dan nog

Begrijp me niet verkeerd, ik ben blij dat jullie willen helpen en codedump is niet echt overzichtelijk.

Hier een screenshot van de memory diag session: http://imgur.com/a/cI0bn

[defiant]

Damic schreef op donderdag 25 mei 2017 @ 14:23:
Elke update komt er ongeveer 2MB bij (update is instelbaar van 10 tot 60 minuten wachten).

Blijft dat toenemen zonder dat het afneemt of neemt het uiteindelijk ook wel weer af als het maar lang genoeg draait? Een snelle manier om te weten of je het echt een memory leak is, is door het geheugen van je programma te beperken. Als dat zo is kan de garbage collector op een gegeven geen geheugen meer vrijmaken en dan krijg je een out-of-memory exception. Bijvoorbeeld met deze tool, maar er zijn vast ook anderen.

Blijft je programma gewoon functioneren met weinig geheugen, dan heb je geen hard geheugen lek, hooguit objecten die te lang worden vastgehouden, bijvoorbeeld inderdaad door het niet aanroepen van dispose. Onder .NET heb je geen directe controle over wanneer de garbage collector langs komt en geheugen daadwerkelijk vrij wordt gegeven.

Disposable objecten die niet gedisposed worden zorgen wel vaak voor onnodig veel connecties naar resources, zie ook dit antwoord op stackoverflow. Of deze ook echt harde memory-leaks veroorzaken ligt eraan of disposable classes een destructor heeft die de finalizer kan aanroepen. Zie daarvoor ook deze andere discussie op stackoverflow. Dat zal met classes uit het .NET framework altijd wel zo zijn.

[Damic]

@defiant bedankt voor de tool, het is echt een lek, als ik het geheugen beperk tot 50MB en dan een update doen dan crasht het programma.

Ik heb momenteel een aantal functies/threads uitgezet, ben eens benieuwd.

[defiant]

Damic schreef op vrijdag 26 mei 2017 @ 00:33:
@defiant bedankt voor de tool, het is echt een lek, als ik het geheugen beperk tot 50MB en dan een update doen dan crasht het programma.

Ik zie dat je sqllite gebruikt, de standaard library daarvoor maakt gebruikt van een interop dll die niet native .NET is (en dus een externe resource is die gedisposed moet worden), dat lijkt me typisch een kandidaat waarin een memory leak zou kunnen optreden. Zie ook de FAQ:
(17) Why is System.Data.SQLite leaking memory, resources, etc?

Daar zou je misschien nog naar kunnen kijken.

[ Voor 6% gewijzigd door defiant op 26-05-2017 00:43 ]

[Damic]

Tja dat zou kunnen, maar volgens mij niet. In ieder geval hier is de classe: https://pastebin.com/M8WnZrJZ best is gewoon c/p in VS.

Origineel is door Kati Maya geschreven, maar deze versie is al veel beter kwa SQL injection (nog niet 100% maar ik kom er wel) en ik kan er multi threaded mee werken (dus meerdere threads data uit/in de db halen/steken)

[defiant]

Damic schreef op vrijdag 26 mei 2017 @ 01:15:
Tja dat zou kunnen, maar volgens mij niet. In ieder geval hier is de classe: https://pastebin.com/M8WnZrJZ best is gewoon c/p in VS.

Origineel is door Kati Maya geschreven, maar deze versie is al veel beter kwa SQL injection (nog niet 100% maar ik kom er wel) en ik kan er multi threaded mee werken (dus meerdere threads data uit/in de db halen/steken)

Op zich wordt in die class wel goed de connectie gedisposed, dit lijkt ook wel goed te gaan als je hem telkens instantieert voor elke database call die je maakt. Maar hergebruik je deze class door je applicatie als singleton, dan lijkt me dat in eerste instantie niet echt thread safe.

Visual Basic .NET:

   Private Sub CloseConn(Optional CloseAll As Boolean = False)
        'If CloseAll Then iOpenCon = 1
        If iOpenCon > 0 Then
            iOpenCon -= 1
            If iOpenCon < 1 Then
                iOpenCon = 0
                conn.Close()
                conn.Dispose()
            End If
            'Debug.Write("c" & iOpenCon & ",")
        End If
    End Sub

Hij disposed alleen de connectie als iOpenCon 0 is, in een singleton scenario heb je die garantie niet met multithreading omdat de field variable iOpenCon increment/decrement niet thread-safe wordt benaderd. Je zou die debug regel kunnen uitcommentariëren en kunnen kijken of dispose ook echt wordt aangeroepen.

Sowieso is SQLite zelf vaak niet thread-safe, kijk ook verder hier: One SQLiteConnection per thread?

[Damic]

Mmmh k had dat zo geschreven om dat ik een lockout kreeg (db is locked), dus ik dacht van laat ik dezelfde conn gebruiken dan krijg ik dat niet meer, maar dat heeft er eigenlijk niets mee te maken en is zelfs "dom".

Straks eens bekijken, nu eerst slapen.

Nog wat aan't rond zoeken geweest en blijkbaar als je transaction gebruikt heb je geen db lock error's, dus dat maar geïmplementeerd.

Nu het geheugen verbruik is nog altijd niet onder controle.

[ Voor 28% gewijzigd door Damic op 26-05-2017 16:23 ]

[Damic]

Ik had dotMemory aangezwengeld en nog een paar runs gedaan maar werd er niet wijzer uit behalve dat de threads nog in het geheugen blijven hangen (zelfs als ik geen gc.collect doe) en nog een aantal dingen dat blijft hangen in het geheugen want het geheugen beheer van MS is niet echt goed (ben tot die conclusie gekomen nadat ik die blogspot las)

Ik was wat aan't rond surfen naar memory management en kwam dit tegen: http://arnosoftwaredev.bl...-applications-memory.html na wat aanpassingen voor het gebruik in vb.net en een test run gedaan te hebben het resultaat HOLY FUCK, standaard verbruik is normaal rond de 16MB private en 30MB Shared, na die SetProcessWorkingSetSize()* tedoen is het verbruik (private+shared) maar 7MB

Nu misschien is het iets te vroeg gejuicht maar als dit een oplossing is, dan ben ik blij.

*MS gebruikt deze functie ook als je het programma minimaliseert blijkbaar.

[mulder]

Met een hamer past alles natuurlijk Dit lijkt mij een beetje symptoombestrijding, je hebt een memory leak en dan forceer je het gebruikte geheugen van je applicatie om dit te camoufleren.

https://stackoverflow.com...ngsetsize-whats-the-catch

[farlane]

In welk object gaat dat geheugen zitten volgens jou? In je hoofdpad of in de exceptions etc? Krijg je exceptions?

Roep je die

Visual Basic:

ClearCookies()

ook daadwerkelijk aan?
Kun je de code uitkleden tot de essentie?

[Haan]

Ik snap sowieso het hele probleem nog niet. Ik zie geheugengebruik van maar enkele tientallen MB's? Bijft dat oneindig oplopen ofzo?
De Cloud Explorer in Visual Studio (die geïnstalleerd wordt als je de Azure SDK installeert) van een paar versie terug had pas echt een memory leak, die vrat gewoon langzaam al het beschikbare geheugen op, een proces dat 14GB geheugen gebruikt op een machine met 16GB, dán hebben we het tenminste ergens over

[farlane]

Nja, als je naar verloop van tijd een OOM krijgt is er *iets* niet helemaal lekker.

[Cloud]

mulder schreef op maandag 29 mei 2017 @ 12:34:
Met een hamer past alles natuurlijk Dit lijkt mij een beetje symptoombestrijding, je hebt een memory leak en dan forceer je het gebruikte geheugen van je applicatie om dit te camoufleren.

https://stackoverflow.com...ngsetsize-whats-the-catch

Met ^^ hierin; dit lijkt me niet de juiste weg en is niet echt een oplossing.

Ik zou eerst eens uitzoeken waar dat geheugen nu daadwerkelijk blijft. 2 MB per run moet eenvoudig op te sporen zijn toch?

Damic schreef op donderdag 25 mei 2017 @ 23:24:
[...]
Hier een screenshot van de memory diag session: http://imgur.com/a/cI0bn

Deze screenshots die je gepost hebt, snap ik niet helemaal. De bovenste is denk ik een cpu profile sessie? Ik zie weliswaar geen kolomkoppen maar het verder lijken me het allemaal methodenamen. Onderste screenshot noemt weliswaar allocations maar ik zie verder alleen een methodenaam, dus dat is denk ik ook een stukje uit een cpu profile sessie.

Weet niet met welke IDE je werkt maar in VS2015 en nieuwer, zit in het Diagnostic Tools window de mogelijkheid om memory snapshots te maken. Doe dat direct na het opstarten, doe er nog eentje na update; en bekijk het verschil tussen #2 en #1. Dan kun je nog sorteren op grootste diff in bytes en dat zou je een aardige indicatie moeten geven qua waar je geheugen blijft

[Haan]

farlane schreef op maandag 29 mei 2017 @ 15:43:
Nja, als je naar verloop van tijd een OOM krijgt is er *iets* niet helemaal lekker.

Maar ik lees nergens dat dat gebeurt.. Alleen dat het programma crasht als het geheugen tot 50MB wordt beperkt, maar dat is niet echt een realistisch scenario.

[farlane]

Haan schreef op maandag 29 mei 2017 @ 16:04:
[...]
Maar ik lees nergens dat dat gebeurt.. Alleen dat het programma crasht als het geheugen tot 50MB wordt beperkt, maar dat is niet echt een realistisch scenario.

Wat is wel realistisch dan? De applicatie draait nl de eerste paar "updates" wel goed.

[Damic]

De screenshot is het geheugen gebruik na de 2de memory shot. Dus Program opstarten > update doen > shot nemen > 2de update doen > 2de shot nemen.

@mulder Met een hamer en een slijpschijf past alles
@Haan ja dit blijft oplopen bij elke update.
@farlane

code:

    Public Sub ClearCookies()
        tempCookies = Nothing
        tempCookies = New CookieContainer
    End Sub

meer staat er niet in.

@Cloud vs2017 en direct na het opstarten heeft geen zin vermits ik wel wat data inlaad tijdens de eerste update.

[Cloud]

@Damic dat is niet erg. Zodra je simpelweg twee snapshots hebt kun je het verschil bepalen. Ook al haalt het opstarten al data op, dat maakt voor zo'n vergelijking niet uit. Desnoods neem je het verschil tussen de tweede en derde update.

[Damic]

Voila nieuwe run gedaan, 3 snapshots gemaakt. 1 Ste is die juist na het opstarten, 2de is na 1ste update, 3de is na 2de update.


Het probleem hier mee is dat de verschillen altijd vanaf de base line is enzodus vermits de base line nog "leeg" was zijn de verschillen groter


Edit:

en nu 1 na de eerste update

[ Voor 10% gewijzigd door Damic op 29-05-2017 19:04 ]

[farlane]

Damic schreef op maandag 29 mei 2017 @ 18:12:
@farlane

code:

    Public Sub ClearCookies()
        tempCookies = Nothing
        tempCookies = New CookieContainer
    End Sub

meer staat er niet in.

Dat weet ik, maar roep je 'em ook aan? Als je dat niet doet, maar je voegt wel telkens nieuwe cookies toe kan het geheugengebruik oplopen.

[Damic]

Hazo ja elke keer voor een nieuwe run.

code:

Private Sub BGW_DoWork(sender As Object, e As System.ComponentModel.DoWorkEventArgs) Handles BGW.DoWork
        Dim m As Match
        Dim iLogId As Integer
        Try
            ClearCookies()
...

[farlane]

Probeer eens te lokaliseren waar de allocaties gedaan worden in je code dan, je geeft (blijkbaar een onvolledige) lap code met alle cruft er nog om heen. Probeer de essentie van je "memory leak" eens te lokaliseren.

Ook ik ben er nog niet van overtuigd dat je ueberhaupt een probleem hebt overigens. (En als je er wel een zou hebben, dat deze code de boosdoener zou zijn )

[Caelorum]

Loop je niet gewoon tegen een probleem vergelijkbaar als dit aan? https://connect.microsoft...ection-tunnelthroughproxy

Ik weet niet hoeveel requests je uiteindelijk wilt gaan afvuren, maar als het er veel zijn, is het dan niet handiger om iets als HttpClient te gebruiken, zodat je dingen maar 1 keer hoeft te zetten? (Deze wil je overigens niet constant opnieuw aanmaken in een loop ivm memory leaks, maar hergebruiken)

[Damic]

Ha great a MS website die een SEC_ERROR_OCSP_INVALID_SIGNING_CERT geeft.

Anyway ik doe minimum 10 requests, en momenteel 12 voor mijn account.

@farlane zou best kunnen dat het in SQLite zit. Ik gaan eens een oude versie erover zetten en zien of het dan opgelost is. Zoja dan zit het in SQLite en anders is het zoeken. Voila 1.0.8.9 opgestart en ik zal het resultaat morgen weten.

[ Voor 8% gewijzigd door Damic op 29-05-2017 21:35 ]

[MerijnB]

Damic schreef op maandag 29 mei 2017 @ 21:30:
Ha great a MS website die een SEC_ERROR_OCSP_INVALID_SIGNING_CERT geeft.

Gebruik je Firefox?

nieuws: Firefox-gebruikers hebben problemen met verbinding met Microsoft-dien...

[Damic]

@MerijnB het was een kwestie van wachten.

@Caelorum en @farlane juist even gekeken naar het geheugen gebruik en is toch gestegen met 10MB, nu is het wel zo dit is nog oude code en kan dus andere bugs hebben.

*Gisteren begonnen op 12680/36300 nu 22940/36704 (9 updates = 1140kB/upd)

[sig69]

Kan je het interval niet tijdelijk even wat korter maken en dan een snapshot maken als er echt serieus geheugen gebruikt wordt (een paar 100MB ofzo)? Een toename van 1-2MB is peanuts natuurlijk, daar ga je niets wijzer van worden.

[Gomez12]

Hoeveel geheugen heb je eigenlijk vrij en hoe groot zijn je inserts?

Ik kan me zo iets voorstellen dat een sqlite als basis hanteert (mits je genoeg vrij geheugen hebt) dat een insert naar schijf geschreven wordt voor acid-compliance, maar daarna het gewoon in het geheugen laat staan.
Het zou vrij inefficiënt en traag (kunnen zijn afhankelijk van hoe je ertegen aan kijkt) als een insert naar schijf geschreven wordt, uit het geheugen gemieterd om dan bij de 1e query het weer van schijf te laden en in het geheugen te zetten, laat het dan lekker in het geheugen staan als je toch genoeg free memory hebt.

[Cloud]

Damic schreef op maandag 29 mei 2017 @ 18:56:
Voila nieuwe run gedaan, 3 snapshots gemaakt. 1 Ste is die juist na het opstarten, 2de is na 1ste update, 3de is na 2de update.
[afbeelding]

Het probleem hier mee is dat de verschillen altijd vanaf de base line is enzodus vermits de base line nog "leeg" was zijn de verschillen groter
[afbeelding]

Edit:

en nu 1 na de eerste update
[afbeelding]

Hmm, ik kan in VS2015 een ander snapshot kiezen om mee te vergelijken zodat je niet altijd met de baseline hoeft te vergelijken. Maar wellicht zit dat niet in de community (?) versie die jij gebruikt? Ik weet dat op het gebied van analyse er wel wat verschillen tussen de gratis en betaalde versie zitten.

Maar goed; als jij zelf naar je tweede screenshot kijkt, zie je dan objecten die leven die je niet verwacht? Bijvoorbeeld het aantal bestaande MemoryStreams. En als je nog een paar updates later bent, blijft dat aantal toenemen en verwacht jij ook dat dat gebeurt? Met andere woorden, kun je dat gezien je code uitleggen als 'verwachte werking' of als een bijkomstigheid die je niet had voorzien?

Memory leaks / het opsnoepen van geheugen is een spelletje van kijken wat het resultaat van je geheugengebruik is en dat proberen te 'mappen' op wat jij voor code hebt om te kijken of het past of niet

[Damic]

We zitten nu op 37108/37230k

Zou het helpen dat ik de Performance Profile op Native zet in de plaats van Managed jup dit kan ik wel lezen

@Gomez12 vrij klein
@Cloud die memorystreams zijn dat de deze:
Using memStream As Stream = New MemoryStream() of
Using fileStream As FileStream = New FileStream(Files(i), FileMode.Open, FileAccess.Read) of
Using requestStream As Stream = postReq.GetRequestStream() of
Using postreqreader As New StreamReader(postresponse.GetResponseStream())
enzo of zijn dat meer algemene streams?

Mmmh dat is raar, waarom komt in elke request die figuren terug?

[ Voor 15% gewijzigd door Damic op 30-05-2017 19:18 ]

[sig69]

Damic schreef op dinsdag 30 mei 2017 @ 19:07:
We zitten nu op 37108/37230k

Nog steeds veel te weining om je ergens zorgen om te maken of duidelijk een memoryleak te kunnen spotten.

...
Mmmh dat is raar, waarom komt in elke request die figuren terug?
[afbeelding]
[afbeelding]

Dat zal elk windows form doen op het moment dat die aangemaakt wordt. Maar dat zijn bytes in dat overzicht, dus enkele kilobytes totaal. Je focust een beetje op de verkeerde dingen...

[Damic]

@sig69 ja dat kan best zijn dat ie dat aanmaakt als je het form aanspreekt maar ook telkens als je een update doet, als alles al bestaat? Is nogal raar.

De getallen dat ik geef is Private memory/shared memory, dit vanuit TaskManager

Voila nu een snapshot genomen en de volgende is morgen vroeg.

[ Voor 15% gewijzigd door Damic op 30-05-2017 20:59 ]

[sig69]

Dat is moelijk te zeggen zonder je hele code. Ik zie wel een referentie naar een frmSettings in je functie, dus dat zal 'm wel zijn.

[Damic]

Snapshots van deze nacht

[ Voor 6% gewijzigd door Damic op 31-05-2017 07:25 ]

[Cloud]

Als je de inhoud van snapshot #3 bekijkt zou je nu wel moeten kunnen zien waar die 10 MB ongeveer gebleven is. Als je die 10 MB geheugengebruik niet onder een enkel type vind moet je gaan kijken waar die 12 duizend allocaties gebleven zijn.

[Haan]

De vraag is volgens mij al eerder voorbij gekomen, maar kan het ook niet gewoon een of andere caching zijn? Want laten we eerlijk zijn, een stijging van 10MB geheugengebruik in 9 uur, zou ik nooit 1 seconde over hebben nagedacht dat dat überhaupt een probleem zou zijn.

[farlane]

Feit is dat er vanuit de Http_Request functie een referentie is naar frmSettings, dus elke keer als je de functie aanroept wordt hiervan een instantie aangemaakt die weer 1 miljoenmiljard andere allocaties doet.

Sloop dat er eens uit, het is sowieso een baggerconstructie.

[ Voor 7% gewijzigd door farlane op 31-05-2017 10:22 ]

[Lethalis]

My eyes hurt, en het ligt in dit geval niet aan VB.

Anyways, als je die code nou eens verder uitsplitst in afzonderlijke functies die elk een specifiek doel hebben, dan krijg je ook veel duidelijker in die memory analyzers te zien aan welk deel van de code het ligt.

Sowieso is het - op zijn zachts gezegd - erg opvallend dat frmSettings zo vaak wordt geïnitialiseerd. In jouw codevoorbeeld gebruik je dit alleen om de referer te zetten (voor zover ik het kan zien op deze manier).

Ik zou eventuele settings gewoon via een class - of als het er niet te veel zijn - gewoon als parameter van de functie meegeven.

Dit wordt nog belangrijker als je dingen multithreaded wil gaan maken. De input van elke functie per thread mag immers niet gaandeweg wijzigen en een Windows Form is nou niet bepaald thread safe.

PS:
Omdat ik het niet kan laten: erg grappig om te zien dat iemand die 3 jaar jonger is dan ik naming conventions gebruikt als bUseForm en sParameters. Dat zijn van die dingen die ik er uitsloop in legacy code als ik ze tegenkom

ByVal verwijder ik ook altijd. ByVal is namelijk standaard. En ByRef kom ik het liefst helemaal niet tegen.

In het kader van less is more.

Daarnaast vind ik de casing erg verwarrend. Lower case zou voor lokale variabelen moeten zijn, upper case voor module of class variabelen. Als ik nu "Files" lees, dan denk ik dat je ze ergens anders vandaan haalt. Dat soort kleine details.

List(of T) is al een reference type. Het is dus niet nuttig hem ByRef door te geven. Je geeft nu de intentie door om de lijst te wijzigen in de functie. Niet eens de inhoud van de lijst, maar gewoon de hele lijst.

It's all so confusing

[ Voor 33% gewijzigd door Lethalis op 31-05-2017 11:07 ]

[Damic]

50kB groei nog, en allemaal external code nu eens zien wat die managed zegt.

@Haan als ik zien naar de sqlite identifiers dan staan die allemaal mooi op 0, het zou natuurlijk wel kunnen zijn dat er nog iets blijft hangen.

@farlane dat ik daar heb over kunnen zien tja niet moeilijk dat ik geheugen groei heb eventueel zou ik die wel op shared kunnen zetten en dan vermoed ik dat ik dat probleem ook niet meer heb.

@Lethalis zie farlane en verder uitspitten, heb dat geprobeerd en is niet te doen, alles wat in de bgw staat moet achter elkaar gedaan worden (behalve sommige delen die al een aparte thread starten.
Byval: ja blijkbaar is dat veranderd tegenover VB6, volgens mij was het daar gewenst dat je daar byval zette.

Edit: Als ik geen gc collect doen dan groeit het managed memory met 71kB maar als ik dan gaan zien zien ik veel node <object>'s nog in leven zijn en dat is een goede 387kB

Plaatjes zeggen meer dan veel tekst: http://imgur.com/a/EfK9o
1. Unmanaged
2. Managed
3. Managed detail
4. Managed met gc.collect na een run
5. Managed detail met gc.collect na een run

Nachtje laten draaien dan weet ik meer.

Van 12712/39556 naar 13996/37144 dus op een nacht is dat een groei van 1284kB in de prive werkset. We zijn er bijna.

[ Voor 25% gewijzigd door Damic op 01-06-2017 06:41 ]