C sharp ram forbrug

[Ulrik Smed]

Hey, er der stadig nogen her? :-)

Hvordan kan det være at mit forholdsvis lille program bruger op til næsten
100MB ram? Det er et lydmåleprogram der sampler og beregner og viser et par
grafer levende på skærmen. Når det kører og jeg kigger i joblisten hopper
ramforbruger op og ned mellem ca. 40 og 90MB. Og programmet holder af og til
en pause på op til et helt sekund, hvilket er lidt forstyrrende. Virker som
om den konstant allokerer ram og frigiver/garbage-collecter det.

Jeg bruger et par bitmaps til graferne, og har oprettet dem permanent så de
ikke oprettes og nedlægges ved hver redraw. Visse andre ting opretter og
nedlægger jeg inde i funtioner, f.eks. grafik objekter til at få adgang til
tegnefunktionerne. Men fylder de ret meget?

--
Ulrik Smed
Aarhus

[Erik Nielsen]

http://www.howtogeek.com/128130/htg-explains-why-its-good-that-your-computers-ram-is-full

[Ulrik Smed]

Det der handler vist mest om fil-tilgang og cache og swapping og den slags.
Jeg laver ingen fil-tilgang i programmet (bortset fra at indlæse en lille
txt fil under opstart), og disken swapper ikke, der er ram nok. Det jeg
fisker efter er om jeg kan gøre noget for at undgå at ram allokeres og
frigives konstant, for jeg tror det er derfor der er 'huller' i afviklingen.
Skidt med hvis det bruger 100MB permanent.

--
Ulrik Smed
Aarhus

[Arne Vajhøj]

On 12/14/2012 2:49 PM, Ulrik Smed wrote:
> Hey, er der stadig nogen her? :-)

Ja.

Kig på kalenderen. Den viser 2012 ikke 2002.

40-90 MB er ikke ret meget idag.

Hello world i console bruger 1.5 MB og hello world i win forms
fylder 5 MB.

Hvis du har lidt lyd, lidt grafer og lidt billeder, så
lyder 40-90 MB ganske realistisk.

Den RAM koster ca. 2-3 kroner med dagens RAM priser.

Hvorfor skulle man fjerne funktionalitet fra nogle af
de involverede komponenter for at spare på det?

Arne

[Ulrik Smed]

Det skal man heller ikke, men man kunne måske spare noget kørselstid på ikke
at allokere og frigive det hele tiden. Skal jeg over i C eller C++ (ikke
dotnet) for at lave det lidt mere effektivt (hastighed) og unmanaged?

--
Ulrik Smed
Aarhus

[Arne Vajhøj]

Har du nogen grund til at tro at allokering og deallokering
bruger en stor del af CPU tiden?

Det er ret sjældent at det er tilfældet.

> Skal jeg over i C eller C++ (ikke
> dotnet) for at lave det lidt mere effektivt (hastighed) og unmanaged?

Hvis hyppig allokering og deallokering er et problem, så skal
designet af koden ændres ikke sproget.

Hvis vi snakker hyppig allokering og deallokering af mange
short lived objekter, så vil antagelsen være at managed GC er
hurtigere end unmanaged eksplicit deallokering.

Fordelen ved unmanaged eksplicit deallokering er den er mere
jævn, hvilket er et absolut must for brug der kræver real time
eller real time lignende egenskaber.

Arne

[Ulrik Smed]

Arne Vajhøj wrote:
> On 12/15/2012 12:46 AM, Ulrik Smed wrote:
>> Arne Vajhøj wrote:
>>> Hvorfor skulle man fjerne funktionalitet fra nogle af
>>> de involverede komponenter for at spare på det?
>>
>> Det skal man heller ikke, men man kunne måske spare noget kørselstid
>> på ikke at allokere og frigive det hele tiden.
>
> Har du nogen grund til at tro at allokering og deallokering
> bruger en stor del af CPU tiden?

Jeg synes pauserne i programmet kommer i takt med at ram-forbruget stepper
ned fra f.eks 80 til 40MB. Så jeg mistænker garbage collection for at være
årsagen.

> Fordelen ved unmanaged eksplicit deallokering er den er mere
> jævn, hvilket er et absolut must for brug der kræver real time
> eller real time lignende egenskaber.

Det er præcis der jeg vil hen. De lange pauser vil jeg godt undgå, også
selvom det koster lidt gennemsnitlig performance. Hvordan ændrer jeg
designet af koden, så den ikke implicit allokerer og frigiver hele tiden.
Hvorfor hjælper det ikke at have objekterne oprettet permanent, og undlade
at oprette/nedlægge dem inde i funktionerne (Mine bitmaps og lydbuffere,
f.eks. Jeg har ikke testet ordentligt endnu med f.eks. graphics objekter
fordi jeg antager de er ret små)? Jeg har ikke behov for at frigive, det gør
såmænd ikke noget at ram forbruget er permanent højt hvis det skulle være,
men jeg har en fornemmelse af at det høje forbrug kun skyldes ophobede
objekter der først bliver frigivet senere, i 'klumper'.

--
Ulrik Smed
Aarhus

[Arne Vajhøj]

On 12/15/2012 10:51 AM, Ulrik Smed wrote:
> Arne Vajhøj wrote:
>> On 12/15/2012 12:46 AM, Ulrik Smed wrote:
>>> Arne Vajhøj wrote:
>>>> Hvorfor skulle man fjerne funktionalitet fra nogle af
>>>> de involverede komponenter for at spare på det?
>>>
>>> Det skal man heller ikke, men man kunne måske spare noget kørselstid
>>> på ikke at allokere og frigive det hele tiden.
>>
>> Har du nogen grund til at tro at allokering og deallokering
>> bruger en stor del af CPU tiden?
>
> Jeg synes pauserne i programmet kommer i takt med at ram-forbruget stepper
> ned fra f.eks 80 til 40MB. Så jeg mistænker garbage collection for at være
> årsagen.

GC vil typisk tage 5-500 millisekunder. Med så lidt memory burde det
være i den lavere ende.

Hvis pauserne kan observeres visuelt, så synes jeg ikke at det tyder
på GC som årsagen.

Men det kan naturligvis måles, hvis man vil vide med sikekrhed.

>> Fordelen ved unmanaged eksplicit deallokering er den er mere
>> jævn, hvilket er et absolut must for brug der kræver real time
>> eller real time lignende egenskaber.
>
> Det er præcis der jeg vil hen. De lange pauser vil jeg godt undgå, også
> selvom det koster lidt gennemsnitlig performance. Hvordan ændrer jeg
> designet af koden, så den ikke implicit allokerer og frigiver hele tiden.

????

> Hvorfor hjælper det ikke at have objekterne oprettet permanent, og undlade
> at oprette/nedlægge dem inde i funktionerne (Mine bitmaps og lydbuffere,
> f.eks. Jeg har ikke testet ordentligt endnu med f.eks. graphics objekter
> fordi jeg antager de er ret små)?

Det hjælper også.

Men hvsi det ikke har nogen målbar effekt, så kan det skyldes
at problemet ikke er GC eller at de kritiske allokeringer/deallokeringer
ikke er i din kode men i de libraries du bruger.

> Jeg har ikke behov for at frigive, det gør
> såmænd ikke noget at ram forbruget er permanent højt hvis det skulle være,
> men jeg har en fornemmelse af at det høje forbrug kun skyldes ophobede
> objekter der først bliver frigivet senere, i 'klumper'.

Du kunne starte med at eksperimentere lidt med GC konfiguration.

Læs f.eks.:

http://msdn.microsoft.com/en-us/library/bb384202.aspx

Men jeg tvivler altså på at det hjælper.

Arne

[Ulrik Smed]

Arne Vajh�j wrote:
> On 12/15/2012 10:51 AM, Ulrik Smed wrote:
>>
>> Jeg synes pauserne i programmet kommer i takt med at ram-forbruget

>> stepper ned fra f.eks 80 til 40MB. S� jeg mist�nker garbage
>> collection for at v�re �rsagen.
>
> GC vil typisk tage 5-500 millisekunder. Med s� lidt memory burde det
> v�re i den lavere ende.
>
> Hvis pauserne kan observeres visuelt, s� synes jeg ikke at det tyder
> p� GC som �rsagen.
>
> Men det kan naturligvis m�les, hvis man vil vide med sikekrhed.

Det medf�rer huller i samplingen engang imellem. Bufferen er ca. 100ms lang,
og hvis jeg g�r den l�ngere bliver min framerate tilsvarende lavere, det vil
jeg helst undg�. Det kan selvf�lgelig stadig skyldes andet end GC.

>>> Fordelen ved unmanaged eksplicit deallokering er den er mere

>>> j�vn, hvilket er et absolut must for brug der kr�ver real time

>>> eller real time lignende egenskaber.
>>

>> Det er pr�cis der jeg vil hen. De lange pauser vil jeg godt undg�,
>> ogs� selvom det koster lidt gennemsnitlig performance. Hvordan
>> �ndrer jeg designet af koden, s� den ikke implicit allokerer og
>> frigiver hele tiden.
>
> ????

Det jeg mente var at undg� automatisk allokering, og de deraf f�lgende
pauser n�r GC rydder op. Jeg kan umiddelbart se to muligheder.
At s�rge for der ikke bliver allokeret, eller at deallokere 'manuelt'. Jeg
foretr�kker klart den f�rste, det virker smartest og p�nest.

Har rodet lidt mere med det nu, og det ser ud til at 'synderen' er n�r jeg
viser en bitmap i en picturebox med f.eks.
spectrumpicture.Image = spectrumbitmap;
hvor spectrumpicture er en picturebox og spectrumbitmap er en bitmap.

Kan det evt. g�res p� anden m�de s� der ikke allokeres ram til en ny bitmap
eller image hver gang? Jeg forst�r ikke hvorfor det er n�dvendigt at
allokere.

--
Ulrik Smed
Aarhus

[Arne Vajhøj]

On 12/23/2012 3:06 PM, Ulrik Smed wrote:
> Arne Vajh�j wrote:
>> On 12/15/2012 10:51 AM, Ulrik Smed wrote:
>>> Jeg synes pauserne i programmet kommer i takt med at ram-forbruget
>>> stepper ned fra f.eks 80 til 40MB. S� jeg mist�nker garbage
>>> collection for at v�re �rsagen.
>>
>> GC vil typisk tage 5-500 millisekunder. Med s� lidt memory burde det
>> v�re i den lavere ende.
>>
>> Hvis pauserne kan observeres visuelt, s� synes jeg ikke at det tyder
>> p� GC som �rsagen.
>>
>> Men det kan naturligvis m�les, hvis man vil vide med sikekrhed.
>
> Det medf�rer huller i samplingen engang imellem. Bufferen er ca. 100ms lang,
> og hvis jeg g�r den l�ngere bliver min framerate tilsvarende lavere, det vil
> jeg helst undg�. Det kan selvf�lgelig stadig skyldes andet end GC.

100 ms buffer er ikke meget.

Og det er ikke nogen natur lov at st�rre buffer giver d�rligere performance.

Men jeg ville stadig fors�ge at konfigurere GC.

>>>> Fordelen ved unmanaged eksplicit deallokering er den er mere
>>>> j�vn, hvilket er et absolut must for brug der kr�ver real time
>>>> eller real time lignende egenskaber.
>>>
>>> Det er pr�cis der jeg vil hen. De lange pauser vil jeg godt undg�,
>>> ogs� selvom det koster lidt gennemsnitlig performance. Hvordan
>>> �ndrer jeg designet af koden, s� den ikke implicit allokerer og
>>> frigiver hele tiden.
>>
>> ????
>
> Det jeg mente var at undg� automatisk allokering, og de deraf f�lgende
> pauser n�r GC rydder op. Jeg kan umiddelbart se to muligheder.
> At s�rge for der ikke bliver allokeret, eller at deallokere 'manuelt'. Jeg
> foretr�kker klart den f�rste, det virker smartest og p�nest.
>
> Har rodet lidt mere med det nu, og det ser ud til at 'synderen' er n�r jeg
> viser en bitmap i en picturebox med f.eks.
> spectrumpicture.Image = spectrumbitmap;
> hvor spectrumpicture er en picturebox og spectrumbitmap er en bitmap.
>
> Kan det evt. g�res p� anden m�de s� der ikke allokeres ram til en ny bitmap
> eller image hver gang? Jeg forst�r ikke hvorfor det er n�dvendigt at
> allokere.

N�r du bruger et f�rdigt framework, s� sparer du en masse kode, men
mister noget fleksibilitet.

Det overrasker mig ikke at allokeringerne sker langt nede i frameworket
og derfor er uden for din kontrol.

Arne

[Ulrik Smed]

Arne Vajh�j wrote:
> On 12/23/2012 3:06 PM, Ulrik Smed wrote:
>>
>> Det medf�rer huller i samplingen engang imellem. Bufferen er ca.
>> 100ms lang, og hvis jeg g�r den l�ngere bliver min framerate
>> tilsvarende lavere, det vil jeg helst undg�. Det kan selvf�lgelig
>> stadig skyldes andet end GC.
>
> 100 ms buffer er ikke meget.
>
> Og det er ikke nogen natur lov at st�rre buffer giver d�rligere
> performance.

N�hh, men buffer-full eventet vil jo trigge f�rre gange i sekundet med en
l�ngere buffer. Og det er umiddelbart smartest og simplest at lade det event
trigge beregning og redraw. Jeg ville ogs� f� l�ngere latency p� billedet
med l�ngere buffer, ogs� selvom jeg regner og tegner mindre bidder af
bufferen ad gangen.

> Men jeg ville stadig fors�ge at konfigurere GC.

Jeg l�ste lidt om den via dine links, og det s� ud til dens default
konfiguration faktisk er OK til mit form�l.

>> Det jeg mente var at undg� automatisk allokering, og de deraf
>> f�lgende pauser n�r GC rydder op. Jeg kan umiddelbart se to
>> muligheder. At s�rge for der ikke bliver allokeret, eller at deallokere
>> 'manuelt'. Jeg foretr�kker klart den f�rste, det virker smartest og
>> p�nest. Har rodet lidt mere med det nu, og det ser ud til at 'synderen'
>> er
>> n�r jeg viser en bitmap i en picturebox med f.eks.
>> spectrumpicture.Image = spectrumbitmap;
>> hvor spectrumpicture er en picturebox og spectrumbitmap er en bitmap.
>>
>> Kan det evt. g�res p� anden m�de s� der ikke allokeres ram til en ny
>> bitmap eller image hver gang? Jeg forst�r ikke hvorfor det er
>> n�dvendigt at allokere.
>
> N�r du bruger et f�rdigt framework, s� sparer du en masse kode, men
> mister noget fleksibilitet.

Det var lidt derfor jeg overvejede f.eks. C eller C++ uden dotnet.

> Det overrasker mig ikke at allokeringerne sker langt nede i
> frameworket og derfor er uden for din kontrol.

Det kunne det godt tyde p�. Men der plejer jo ogs� tit at v�re en lille
h�ndfuld forskellige m�der at g�re tingene p�. Jeg g�tter p� den m�ske laver
en mellembuffer til hvis der skal skaleres eller interpoleres eller noget.
Hvis der nu lige var et flag man kunne s�tte for at bypass'e den slags.

--
Ulrik Smed
Aarhus

[Arne Vajhøj]

On 12/26/2012 2:21 PM, Ulrik Smed wrote:
> Arne Vajh�j wrote:
>> On 12/23/2012 3:06 PM, Ulrik Smed wrote:
>>>
>>> Det medf�rer huller i samplingen engang imellem. Bufferen er ca.
>>> 100ms lang, og hvis jeg g�r den l�ngere bliver min framerate
>>> tilsvarende lavere, det vil jeg helst undg�. Det kan selvf�lgelig
>>> stadig skyldes andet end GC.
>>
>> 100 ms buffer er ikke meget.
>>
>> Og det er ikke nogen natur lov at st�rre buffer giver d�rligere
>> performance.
>
> N�hh, men buffer-full eventet vil jo trigge f�rre gange i sekundet med en
> l�ngere buffer. Og det er umiddelbart smartest og simplest at lade det event
> trigge beregning og redraw. Jeg ville ogs� f� l�ngere latency p� billedet
> med l�ngere buffer, ogs� selvom jeg regner og tegner mindre bidder af
> bufferen ad gangen.

Nu g�r jeg ikke selv i den slags.

Men umiddelbart ville jeg da bruge bruge en baggrundtr�d til
at fylde buffer med og lade resten v�re s� uafh�ngig af den
som muligt.

Hvis man venter p� buffer fuld, s� skal man da f� problemer
med klumper.

>> Men jeg ville stadig fors�ge at konfigurere GC.
>
> Jeg l�ste lidt om den via dine links, og det s� ud til dens default
> konfiguration faktisk er OK til mit form�l.

Virkelig?

Du har mistanke om at dit problem skyldes GC pauser og du foretr�kker:

Interactive
For most applications that have a UI.
This is the default mode when concurrent garbage collection is enabled.

over:

SustainedLowLatency
For applications that have time-sensitive operations for a contained but
potentially longer duration of time during which interruptions from the
garbage collector could be disruptive

??

>>> Det jeg mente var at undg� automatisk allokering, og de deraf
>>> f�lgende pauser n�r GC rydder op. Jeg kan umiddelbart se to
>>> muligheder. At s�rge for der ikke bliver allokeret, eller at deallokere
>>> 'manuelt'. Jeg foretr�kker klart den f�rste, det virker smartest og
>>> p�nest. Har rodet lidt mere med det nu, og det ser ud til at 'synderen'
>>> er
>>> n�r jeg viser en bitmap i en picturebox med f.eks.
>>> spectrumpicture.Image = spectrumbitmap;
>>> hvor spectrumpicture er en picturebox og spectrumbitmap er en bitmap.
>>>
>>> Kan det evt. g�res p� anden m�de s� der ikke allokeres ram til en ny
>>> bitmap eller image hver gang? Jeg forst�r ikke hvorfor det er
>>> n�dvendigt at allokere.
>>
>> N�r du bruger et f�rdigt framework, s� sparer du en masse kode, men
>> mister noget fleksibilitet.
>
> Det var lidt derfor jeg overvejede f.eks. C eller C++ uden dotnet.
>
>> Det overrasker mig ikke at allokeringerne sker langt nede i
>> frameworket og derfor er uden for din kontrol.
>
> Det kunne det godt tyde p�. Men der plejer jo ogs� tit at v�re en lille
> h�ndfuld forskellige m�der at g�re tingene p�. Jeg g�tter p� den m�ske laver
> en mellembuffer til hvis der skal skaleres eller interpoleres eller noget.
> Hvis der nu lige var et flag man kunne s�tte for at bypass'e den slags.

Du kan jo checke docs for de relevante klasser, men jeg tvivler.

Arne

[Ulrik Smed]

Arne Vajh�j wrote:
> On 12/26/2012 2:21 PM, Ulrik Smed wrote:
>> Arne Vajh�j wrote:
>>> On 12/23/2012 3:06 PM, Ulrik Smed wrote:
>>>>
>>>> Det medf�rer huller i samplingen engang imellem. Bufferen er ca.
>>>> 100ms lang, og hvis jeg g�r den l�ngere bliver min framerate
>>>> tilsvarende lavere, det vil jeg helst undg�. Det kan selvf�lgelig
>>>> stadig skyldes andet end GC.
>>>
>>> 100 ms buffer er ikke meget.
>>>
>>> Og det er ikke nogen natur lov at st�rre buffer giver d�rligere
>>> performance.
>>
>> N�hh, men buffer-full eventet vil jo trigge f�rre gange i sekundet
>> med en l�ngere buffer. Og det er umiddelbart smartest og simplest at
>> lade det event trigge beregning og redraw. Jeg ville ogs� f� l�ngere
>> latency p� billedet med l�ngere buffer, ogs� selvom jeg regner og
>> tegner mindre bidder af bufferen ad gangen.
>
> Nu g�r jeg ikke selv i den slags.
>
> Men umiddelbart ville jeg da bruge bruge en baggrundtr�d til
> at fylde buffer med og lade resten v�re s� uafh�ngig af den
> som muligt.

S�dan tror jeg faktisk det allerede er. Jeg har ikke selv skrevet
ops�tningen af streamingen, det er fra et lille lyd-recorder eksempel. Jeg
har rodet lidt med backgroundworker til beregninger og drawing, skal have
leget lidt mere med det.

> Hvis man venter p� buffer fuld, s� skal man da f� problemer
> med klumper.

??
Man kan jo ikke bruge indholdet f�r det er til stede, man er da n�dt til at
vente til den er fuld og man f�r et event. Ellers skal man tracke hvor fuld
den er, med h�jere rate end buffer-full eventet, det bliver noget rod, jeg
tror slet ikke filler-pointeren er tilg�ngelig, det er sikkert en hardware
DMA counter i lydkortet.

>>> Men jeg ville stadig fors�ge at konfigurere GC.
>>
>> Jeg l�ste lidt om den via dine links, og det s� ud til dens default
>> konfiguration faktisk er OK til mit form�l.
>
> Virkelig?
>
> Du har mistanke om at dit problem skyldes GC pauser og du foretr�kker:
>
> Interactive
> For most applications that have a UI.
> This is the default mode when concurrent garbage collection is
> enabled.
> over:
>
> SustainedLowLatency
> For applications that have time-sensitive operations for a contained
> but potentially longer duration of time during which interruptions
> from the garbage collector could be disruptive
>
> ??

Fra: http://msdn.microsoft.com/en-us/library/at1stbec.aspx
"By default, the runtime uses concurrent garbage collection, which is
optimized for latency". Jeg har m�ske misforst�et noget, men det var den
s�tning der fik mig til at t�nke at s� er der nok ingen grund til at �ndre
det.

Jeg vil ogs� meget hellere l�se det p� en p�nere m�de, ved at undg�
allokeringerne.

--
Ulrik Smed
Aarhus

[Arne Vajhøj]

On 12/27/2012 8:47 PM, Ulrik Smed wrote:

> Arne Vajhøj wrote:
>> On 12/26/2012 2:21 PM, Ulrik Smed wrote:

>>> Arne Vajhøj wrote:
>>>> On 12/23/2012 3:06 PM, Ulrik Smed wrote:
>>>>>

>>>>> Det medfører huller i samplingen engang imellem. Bufferen er ca.
>>>>> 100ms lang, og hvis jeg gør den længere bliver min framerate
>>>>> tilsvarende lavere, det vil jeg helst undgå. Det kan selvfølgelig

>>>>> stadig skyldes andet end GC.
>>>>
>>>> 100 ms buffer er ikke meget.
>>>>

>>>> Og det er ikke nogen natur lov at større buffer giver dårligere
>>>> performance.
>>>
>>> Næhh, men buffer-full eventet vil jo trigge færre gange i sekundet
>>> med en længere buffer. Og det er umiddelbart smartest og simplest at
>>> lade det event trigge beregning og redraw. Jeg ville også få længere
>>> latency på billedet med længere buffer, også selvom jeg regner og

>>> tegner mindre bidder af bufferen ad gangen.
>>

>> Nu gør jeg ikke selv i den slags.
>>
>> Men umiddelbart ville jeg da bruge bruge en baggrundtråd til
>> at fylde buffer med og lade resten være så uafhængig af den
>> som muligt.
>
> Sådan tror jeg faktisk det allerede er. Jeg har ikke selv skrevet
> opsætningen af streamingen, det er fra et lille lyd-recorder eksempel. Jeg

> har rodet lidt med backgroundworker til beregninger og drawing, skal have
> leget lidt mere med det.
>

>> Hvis man venter på buffer fuld, så skal man da få problemer
>> med klumper.
>
> ??
> Man kan jo ikke bruge indholdet før det er til stede, man er da nødt til at
> vente til den er fuld og man får et event. Ellers skal man tracke hvor fuld
> den er, med højere rate end buffer-full eventet, det bliver noget rod, jeg
> tror slet ikke filler-pointeren er tilgængelig, det er sikkert en hardware
> DMA counter i lydkortet.

Du kan ikke kontrollere en buffer i lydkortet.

Men du kan kontrollere din egen software buffer.

Og tilgang fra flere tråde er en helt klassisk conccurrency
problem som kan løses.

>>>> Men jeg ville stadig forsøge at konfigurere GC.
>>>
>>> Jeg læste lidt om den via dine links, og det så ud til dens default
>>> konfiguration faktisk er OK til mit formål.
>>
>> Virkelig?
>>
>> Du har mistanke om at dit problem skyldes GC pauser og du foretrækker:

>>
>> Interactive
>> For most applications that have a UI.
>> This is the default mode when concurrent garbage collection is
>> enabled.
>> over:
>>
>> SustainedLowLatency
>> For applications that have time-sensitive operations for a contained
>> but potentially longer duration of time during which interruptions
>> from the garbage collector could be disruptive
>>
>> ??
>
> Fra: http://msdn.microsoft.com/en-us/library/at1stbec.aspx
> "By default, the runtime uses concurrent garbage collection, which is

> optimized for latency". Jeg har måske misforstået noget, men det var den
> sætning der fik mig til at tænke at så er der nok ingen grund til at ændre
> det.

Begge de to jeg citerer bruger concurrent GC.

Så forslaget er ikke at skifte fra concurrent GC til
non-concurrent GC men fra concurrent interactive GC til
concurrent sustanined low latency GC.

> Jeg vil også meget hellere løse det på en pænere måde, ved at undgå
> allokeringerne.

Det er ikke pænere at skrive 10000 linier C++ kode end at
ændre på GC policy med 1 linie.

Arne

[Ulrik Smed]

Et par tips til dem der m�tte falder over tr�den, og har samme problemer.

Istedet for at bruge 'Clone' til bitmaps, s� brug
'DrawImageUnscaledAndClipped'. Det sparer at der oprettes og nedl�gges
bitmaps.

Brug 'ref' keywordet n�r bitmaps overf�res til funktioner.

Opret globale grafikobjekter, bitmaps, pens, colors, og lignende, istedet
for at bruge 'new' inde i funktioner til at lave dem midlertidigt.

Jeg skrev i lille 'asteroids' spil her for nylig, og her kunne det m�rkes
meget tydeligere end p� spektrumanalyseren. Det hakkede med j�vne mellemrum
efter at have k�rt et par sekunder. Det blev l�st med ovenst�ende, og
ram-forbruget blev stabilt.

Her er spillet, for de nostalgiske. :-)
http://www.drivehq.com/file/df.aspx/publish/UlrikSmed/PublicFolder/game.exe

--
Ulrik Smed
Aarhus

[Arne Vajhøj]

On 7/21/2013 4:10 PM, Ulrik Smed wrote:
> Et par tips til dem der m�tte falder over tr�den, og har samme problemer.
>
> Istedet for at bruge 'Clone' til bitmaps, s� brug
> 'DrawImageUnscaledAndClipped'. Det sparer at der oprettes og nedl�gges
> bitmaps.

Det giver god mening.

> Brug 'ref' keywordet n�r bitmaps overf�res til funktioner.

Det giver inmgen mening. Bitmap er en reference type ikke en value type.

> Opret globale grafikobjekter, bitmaps, pens, colors, og lignende, istedet
> for at bruge 'new' inde i funktioner til at lave dem midlertidigt.

Hvis det er tunge objekter, s� giver det god mening.

> Jeg skrev i lille 'asteroids' spil her for nylig, og her kunne det m�rkes
> meget tydeligere end p� spektrumanalyseren. Det hakkede med j�vne mellemrum
> efter at have k�rt et par sekunder. Det blev l�st med ovenst�ende, og
> ram-forbruget blev stabilt.

Og jeg forst�r stadig ikke at du ikke ville bruge de f� minutter p�
at pr�ve med en GC beregnet til at undg� periodiske pauser.

Arne