Visual basic prog -> veel RAM

[Verwijderd]

Ik ben bezig met een klein tooltje in Visual Basic (Visual Studio 2008) te schrijven dat pc's automatisch afsluit als de tijd (die gestreamed wordt uit een bestand op een server) bereikt is. Echter, nadat ik heb tooltje gebuilt heb, blijkt dat hij meer dan 10MB aan RAM geheugen gebruikt, wat natuurlijk veel te veel is. Bij wijze van test maakte ik ook een nieuw project aan en builde het, met als enige inhoud het standaard form. Dit bleek al aan 9MB te komen. Kent iemand een manier om het geheugengebruik te beperken? Dit omdat er hier ook pc's zijn met erg weinig beschikbaar RAM.

Als iemand de source zou willen inzien post ik hem wel even, maar ik denk dat dit niet nodig is omdat een standaard form al 9MB in beslag neemt.

Bij voorbaat dank!

[ZpAz]

Als ik me niet vergis kan je ergens bij je project preferences, je programma compilen en optimizen voor speed, of voor size. Geen idee of dat nog zo is, de laatste keer dat ik VB heb aangeraakt is lang geleden in VB 6. Geen idee of het veel scheelt, maar je kan het proberen.

[Verwijderd]

Deze optie heb ik niet teruggevonden, maar toch bedankt voor je bijdrage!

[Snake]

Visual Studio 2008, dus ge gebruikt VB.NET 2008.

Hebt ge veel references in u project? Finalized ge u objecten? Forceer eens een garbage collect. En zet u objecten zelf op Null, en dispose ze daarna als ge ze niet meer nodig hebt.

Ik denk dat het probleem rond u connectie en het ophalen van het bestand zit. Kunt ge de code eens posten?

[RayNbow]

Verwijderd schreef op woensdag 11 juni 2008 @ 19:26:
Beste,

Groeten is niet nodig, zie: Het algemeen beleid #groeten.

Echter, nadat ik heb tooltje gebuilt heb, blijkt dat hij meer dan 10MB aan RAM geheugen gebruikt, wat natuurlijk veel te veel is. Bij wijze van test maakte ik ook een nieuw project aan en builde het, met als enige inhoud het standaard form. Dit bleek al aan 9MB te komen.

Hoe heb je dit geheugengebruik gemeten? Task Manager is niet heel erg betrouwbaar met het vermelden van het geheugengebruik.

[Verwijderd]

De code:

start.vb

Visual Basic .NET:

Public Class start

    Public Sub loadtimes()
        ListBox1.Items.Clear()
        Dim today As String
        today = Now.DayOfWeek

        Dim sr As IO.StreamReader = New IO.StreamReader("\\pct\shutdownapp$\scheduler.txt", System.Text.Encoding.Default)

        Dim line As String
        ' Read and display the lines from the file until the end 
        ' of the file is reached.
        Do
            line = sr.ReadLine()
            If line <> Nothing Then
                ListBox1.Items.Add(line)
            End If
        Loop Until line Is Nothing
        sr.Close()

        For Each cutline As String In ListBox1.Items
            Dim currentline As Array
            currentline = Split(cutline, ";")

            For Each cutcomma As String In currentline
                Dim currentcomma As Array
                currentcomma = Split(cutcomma, ",")

                For Each currentdow As String In currentcomma
                    If currentdow = today Then
                        Dim currenttime As Array
                        currenttime = Split(currentline(1), ":")

                        ListBox2.Items.Clear()
                        ListBox2.Items.Add(currenttime(0))
                        ListBox2.Items.Add(currenttime(1))
                    End If
                Next currentdow
            Next cutcomma
        Next cutline

    End Sub
    Private Sub start_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        loadtimes()
    End Sub

    Private Sub timecheck_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles timecheck.Tick
        Dim hour As String
        Dim minute As String

        hour = Now.Hour
        minute = Now.Minute
        If hour = ListBox2.Items(0) And minute = ListBox2.Items(1) Then
            main.Show()
        End If
    End Sub

    Private Sub getfile_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles getfile.Tick
        loadtimes()
    End Sub
End Class

main.vb (die het werkelijke afsluiten uitvoert)

Visual Basic .NET:

Public Class main

    Public Sub shutdownnow()
        shutdown.Enabled = True
        lblcountdown.Text = 60

    End Sub

    Private Sub shutdown_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles shutdown.Tick
        lblcountdown.Text = lblcountdown.Text - 1

        If lblcountdown.Text = 0 Then
            Dim run = System.Diagnostics.Process.Start("\\pct\shutdownapp$\shutdown.exe", "-s -t 10 -c " & Chr(34) & "Het systeem wordt afgesloten" & Chr(34))
            shutdown.Enabled = False
            Close()
        End If
    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        shutdown.Enabled = False
        Close()
    End Sub

    Private Sub main_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        shutdownnow()
    End Sub

End Class

That's it


EDIT:
Inhoud van het bestand scheduler.txt (\\pct\shutdownapp$\scheduler.txt)

code:

1,2,3,4,5;16:35
6,0;10:40

[Verwijderd]

RayNbow schreef op woensdag 11 juni 2008 @ 19:43:
[...]

Groeten is niet nodig, zie: Het algemeen beleid #groeten.


[...]

Hoe heb je dit geheugengebruik gemeten? Task Manager is niet heel erg betrouwbaar met het vermelden van het geheugengebruik.

OK, ik zal de groeten verwijderen.

Het geheugenverbruik is inderdaad gemeten met Task Manager, wat voor alternatief stel je voor?

[Snake]

Dat zijn heel wat for loopjes, kunt ge dat niet optimaliseren?

[st0p]

Vergeet niet dat nij een .Net programma ook de CLR wordt ingeladen. Als je Windows Forms gebruikt, dan wordt volgens mij ook meteen de hele Windows Forms lib geladen, etc etc.

Inderdaad is de taskmanager niet betrouwbaar, maar 9mb voor een kleine .Net toepassing is imho heel normaal.

[Verwijderd]

st0p schreef op woensdag 11 juni 2008 @ 19:50:
Vergeet niet dat nij een .Net programma ook de CLR wordt ingeladen. Als je Windows Forms gebruikt, dan wordt volgens mij ook meteen de hele Windows Forms lib geladen, etc etc.

Inderdaad is de taskmanager niet betrouwbaar, maar 9mb voor een kleine .Net toepassing is imho heel normaal.

Is er dan een mogelijkheid om (delen van) libs te strippen die niet nodig zijn?

[Verwijderd]

Snake schreef op woensdag 11 juni 2008 @ 19:50:
Dat zijn heel wat for loopjes, kunt ge dat niet optimaliseren?

Heb je misschien een voorstel hoe hetzelfde dan geoptimaliseert bereikt kan worden?

Het verschil tussen een leeg vb bestand (9MB) en het shutdowntooltje (10MB) is eigenlijk ook niet zo groot, maar objectief gezien nog véél te groot!

[st0p]

Bij mijn weten niet.

[edit]
Waarom gebruik je niet gewoon een batchfile die je in de geplande taken knalt?

[ Voor 69% gewijzigd door st0p op 11-06-2008 20:00 ]

[SKiLLa]

De RAM footprint komt inderdaad door de geladen .Net libraries. Veel lager ga je echt niet komen, trouwens, wat is 10 MB anno 2008 ?

Natuurlijk kan het ook in slechts een paar kB (Delphi, C++, Assembler), maar niet met .Net of Java. Classic VB zit daar dan weer tussenin.

Het verschil tussen je "lege" app (9 MB) en je "gevulde" app (10 MB) komt waarschijnlijk door het gebruik (lees: en dus import) van de System.IO namespace ...

PS: Je kan hetzelfde met een simpel VBscriptje bereiken hoor; heb je zelfs nog een lagere footprint ook

[ Voor 40% gewijzigd door SKiLLa op 11-06-2008 20:02 ]

[whoami]

[quote][b]Hebt ge veel references in u project? Finalized ge u objecten?De GC Finalized de objecten ... Dat is iets wat je zelf niet doet.

Forceer eens een garbage collect.

In de meeste gevallen geen goed idee voor de performance.

En zet u objecten zelf op Null, en dispose ze daarna als ge ze niet meer nodig hebt.

Dat gaat leuk gaan. Dispose aanroepen op een object dat NULL is.
Zowiezo maakt het volgens mij ook geen drol uit of je je objecten op NULL zet of niet.
Disposen natuurlijk wel, zodanig dat je unmanaged resources vrijgeeft, maar niet ieder type is IDisposable.

Zowiezo gebruikt een .NET app al wat aan geheugen. Hoe heb je bepaald hoeveel geheugen je app gebruikt ? Heb je een profiler oid gebruikt ?

[MSalters]

Verwijderd schreef op woensdag 11 juni 2008 @ 19:53:
[...]
Is er dan een mogelijkheid om (delen van) libs te strippen die niet nodig zijn?

Dat is zelfs contraproductief!

Ja, je hebt waarschijnlijk 10MB geheugen voor je app ndoig. Maar als een andere .NET app die .NET libraries ook nodig heeft, dan worden ze gedeeld. Je ziet het niet in Task Manager, want jij gebruikt die 10MB echt. Het effect van het delen is alleen dat de totale benodigde hoeveelheid RAM niet een simpele optelsom is.

Het gaat dus fout als je een library stript die je anders zou delen. Zelfs als je maar 1MB overhoudt is het nog 1MB die je niet meer met andere apps kunt delen.

[Verwijderd]

whoami schreef op woensdag 11 juni 2008 @ 20:53:
[quote][b]Hebt ge veel references in u project? Finalized ge u objecten?De GC Finalized de objecten ... Dat is iets wat je zelf niet doet.

[...]
In de meeste gevallen geen goed idee voor de performance.


[...]

Dat gaat leuk gaan. Dispose aanroepen op een object dat NULL is.
Zowiezo maakt het volgens mij ook geen drol uit of je je objecten op NULL zet of niet.
Disposen natuurlijk wel, zodanig dat je unmanaged resources vrijgeeft, maar niet ieder type is IDisposable.

Zowiezo gebruikt een .NET app al wat aan geheugen. Hoe heb je bepaald hoeveel geheugen je app gebruikt ? Heb je een profiler oid gebruikt ?

Ik probeerde net te werken met de "Micrsoft CLR Profiler", maar ik begrijp het nog niet erg goed.

De 10MB die de tool gebruikt, is dit puur RAM of pagefile?


EDIT: Die objecten "finalizen", bespaart dit erg veel resources? Ik zocht informatie op de volgende pagina http://msdn.microsoft.com...stem.object.finalize.aspx, maar het maakt niet echt veel duidelijk.

[ Voor 11% gewijzigd door Verwijderd op 11-06-2008 21:26 ]

[? ?]

..

[ Voor 98% gewijzigd door ? ? op 25-01-2013 09:51 ]

[roy-t]

whoami schreef op woensdag 11 juni 2008 @ 20:53:
[quote][b][message=30226514,noline]

Dat gaat leuk gaan. Dispose aanroepen op een object dat NULL is.
Zowiezo maakt het volgens mij ook geen drol uit of je je objecten op NULL zet of niet.
Disposen natuurlijk wel, zodanig dat je unmanaged resources vrijgeeft, maar niet ieder type is IDisposable.

Zover ik weet is dat op NULL zetten een truukje om de JAVA garbage collector te laten weten dat hij het geheugen voor dat object meteen vrij kan maken bij de volgende garbage collector pass. En dat is vaak beter dan gewoon de reference weghalen. Of het ook bij .Net werkt weet ik niet. En van mijn docent heb ik gehoord dat dat op null zetten nou niet bepaald dramatisch verschil maakt als dat het nog doet.

[joggie]

Om, inderdaad, te weten of het de gui is die je geheugen opeet, zou je ook eens kunnen proberen een console project aan te maken ipv een windows form application.

[Andre-85]

Ik neem aan dat je de build in Release mode gemaakt heb en niet in Debug mode. Dat scheelt ook aardig in geheugen gebruik als ik me niet vergis.

[gorgi_19]

Als je weinig geheugen wilt gebruiken in task manager, vergeet het dan maar om een .Net applicatie te schrijven.

[Exirion]

Voor dit soort progsels:
- .NET
- Visual Basic

[roy-t]

Exirion schreef op donderdag 12 juni 2008 @ 08:16:
Voor dit soort progsels:
- .NET
- Visual Basic

Server sockets openen, afsluittijd stream en dan pc afsluiten. Dat is toch prima voor VB.Net
.NET maakt het mogenlijk om makkelijk de stream van de server te lezene en VB is gewoon een aardige simpele taal waarmee je in dit geval prima het OS mee kan afsluiten. Ik zie niet zo snel waarom VB.NET hier een vreselijke keuze voor is en de memory footprint is erg laag zodra er een 2e .net programma draait. Tevens zegt taakbeheer vrij weinig over echt werkgeheugen verbruik .

Ik zie ook niet zo snel hoe ik/de ts dit zou kunnen doen op een andere manier. Ok het kan prima in C++ ofzo, maar daar ligt de moeilijkheidsgraad en foutgevoeligheid een stuk hoger + dat je nogsteeds bepaalde libs nodig hebt die dan niet zo mooi gedeelt worden voor alle .NET progs maar alleen voor dat C++ programma toegankelijk zijn, dus extreem veel zal het wel niet schelen vermoed ik.

Ik vraag me nu dus erg af waarom het schuddend hoofdje in je post staat, plz explain

[Voutloos]

Het kan idd wel en het is blijkbaar laagdrempeling, maar over 10 MB moet je gewoon niet zeuren.

Steek liever tijd in het verbreden van je kennis (leren van andere talen of andere manieren voor periodieke taken) dan dat je een paar uur, of uberhaupt de tijd van een topicstart, besteedt om een paar lousy kilobytes van een reeds minimale .Net applicatie af te halen.

[bigbeng]

Ik kan me voorstellen dat je schrikt van 10MB op iets wat niet veel meer is dan een batch-bestandje. Als je niet teveel van dit soort programma's hebt draaien is het niet een enorm probleem, 10MB is niet zoveel meer tegenwoordig. Mocht je er wel meerdere hebben draaien, dan zou je ook een service o.i.d. kunnen maken die verantwoordelijk is voor het afvuren van de diverse kleine assemblies. Voordeel is dat het dan binnen 1 runtime gebeurt, waardoor libraries maar 1x geladen worden. Daarmee beperk je in elk geval de overhead weer een beetje.

Maar ik zie dat je een form gebruikt. Is dat nodig? Kun je dit niet met een console app af?

offtopic:
Reacties dat 10MB in deze tijd niet veel is vind ik niet erg constructief. De topicstarter geeft aan dat hij 10MB veel vind vanwege de beperkte RAM beschikbaarheid op sommige PCs. Lijkt mij een valide argument, zeker omdat dit programma blijkbaar resident in het geheugen moet zitten. Om daar als argument tegenover te zetten dan 10MB niet veel is in deze tijd heeft dan weinig zin.

TS, heb jij tijd om je te verdiepen in andere programmeeromgevingen? Ik denk dat .NET iets teveel overhead heeft voor wat jij wil. Gezien de relatief simpele opzet van je programma komen zijn er geschikte talen, zoals C++, die naar native executables compileren.

[Voutloos]

bigbeng schreef op donderdag 12 juni 2008 @ 09:49:

offtopic:
Reacties dat 10MB in deze tijd niet veel is vind ik niet erg constructief. De topicstarter geeft aan dat hij 10MB veel vind vanwege de beperkte RAM beschikbaarheid op sommige PCs. Lijkt mij een valide argument, zeker omdat dit programma blijkbaar resident in het geheugen moet zitten. Om daar als argument tegenover te zetten dan 10MB niet veel is in deze tijd heeft dan weinig zin.

Iedere persoon in dit topic die iets over die 10 MB zegt, geeft meteen een alternatief. Of je gebruikt lekker je je reeds bekende framework, maar zeurt niet over de overhead van dat framework, of je leert gewoon iets anders.

[unclero]

Niet om het een of het ander, maar zo'n tooltje heb ik eergister toevallig gemaakt. In FreeBASIC zelfs (had geen zin in een andere taal ).

Welgeteld 11kb aan executable. En als het progje langer - dan die kwart seconde die het nodig heeft om het bestandje op te halen van de server - zou leven, dan had ik nog kunnen zien dat ie misschien 15kb in het RAM in zou nemen.

[bigbeng]

Voutloos schreef op donderdag 12 juni 2008 @ 09:58:
[...]
Iedere persoon in dit topic die iets over die 10 MB zegt, geeft meteen een alternatief. Of je gebruikt lekker je je reeds bekende framework, maar zeurt niet over de overhead van dat framework, of je leert gewoon iets anders.

offtopic:
of je geeft gelijk het alternatief, zonder dat geneuzel. Zoals de TS het neerzet heeft hij nagedacht over de 10MB. Hij heeft zelfs onderzocht wat een kale app zonder code aan ruimte inneemt. Hij doet er dus duidelijk moeite voor en denkt na. Het lijkt me dan ook niet nodig om hem als een kleuter te behandelen, maar goed, dat is natuurlijk mijn mening.

[MrSleeves]

unclero schreef op donderdag 12 juni 2008 @ 10:08:
Welgeteld 11kb aan executable. En als het progje langer - dan die kwart seconde die het nodig heeft om het bestandje op te halen van de server - zou leven, dan had ik nog kunnen zien dat ie misschien 15kb in het RAM in zou nemen.

executable <> hoeveelheid RAM in gebruik.

Een .NET project met een leeg form (in debug mode) heeft een executable van 28 KB, terwijl het geheugenverbruik een aantal MB is.
Overigens is dat wel weer het voordeel van .NET: het verbruikt (of lijkt te verbruiken) aardig wat geheugen; de executables zijn vaak weer niet zo supergroot.

[.oisyn]

whoami schreef op woensdag 11 juni 2008 @ 20:53:
Zowiezo maakt het volgens mij ook geen drol uit of je je objecten op NULL zet of niet.

Dat maakt weldegelijk uit. Als je referenties naar objecten die je niet meer gebruikt rond laat slingeren kunnen die objecten ook niet vrijgegeven worden - je hebt er immers nog een referentie naar. Denk bijvoorbeeld eens aan een ArrayList implementatie die op een clear() niet z'n daadwerkelijke buffer weggooit als optimalisatie maar tevens ook niet de references op null zet. Jij denkt dat de ArrayList leeg is, terwijl hij in werkelijkheid nog al die objecten in leven houdt.

References op null zetten is zeker wel good practice voor class members en statics. Voor locals maakt het dan natuurlijk wel weer geen zier uit

[Voutloos]

bigbeng schreef op donderdag 12 juni 2008 @ 10:48:
[...]

offtopic:
of je geeft gelijk het alternatief, zonder dat geneuzel. Zoals de TS het neerzet heeft hij nagedacht over de 10MB. Hij heeft zelfs onderzocht wat een kale app zonder code aan ruimte inneemt. Hij doet er dus duidelijk moeite voor en denkt na. Het lijkt me dan ook niet nodig om hem als een kleuter te behandelen, maar goed, dat is natuurlijk mijn mening.

Mijn opmerking gaat ook 100% op voor jouw post.

bigbeng schreef op donderdag 12 juni 2008 @ 09:49:
...10MB is niet zoveel meer tegenwoordig...

En ik behandel niemand als kleuter.

[.oisyn]

bigbeng schreef op donderdag 12 juni 2008 @ 09:49:
Ik kan me voorstellen dat je schrikt van 10MB op iets wat niet veel meer is dan een batch-bestandje. Als je niet teveel van dit soort programma's hebt draaien is het niet een enorm probleem, 10MB is niet zoveel meer tegenwoordig.

Als je 100 van dat soort programma's hebt draaien dan is je geheugengebruik niet ineens 1GB. Het geheugen wat gerapporteerd wordt in je task manager is niet het geheugen dat uniek is voor die applicatie. Veel resources (zoals dll's en assembly's en whatnot) worden gewoon geshared. De kale VM footprint zit waarschijnlijk ook nog bij die 10MB, maar da's ook maar ongeacht hoeveel .Net apps je hebt draaien - terwijl dat geheugen er toch bij elk .Net app in de taskmon bijgeteld wordt.

[Raven]

Verwijderd schreef op woensdag 11 juni 2008 @ 19:26:
...

Offtopic, zou je je DM even aan willen zetten? Heb vraagje over oud topique van jouw...

[bigbeng]

.oisyn schreef op donderdag 12 juni 2008 @ 11:01:
[...]

Als je 100MB van dat soort programma's hebt draaien dan is je geheugengebruik niet ineens 1GB. Het geheugen wat gerapporteerd wordt in je task manager is niet het geheugen dat uniek is voor die applicatie. Veel resources (zoals dll's en assembly's en whatnot) worden gewoon geshared. De kale VM footprint zit waarschijnlijk ook nog bij die 10MB, maar da's ook maar ongeacht hoeveel .Net apps je hebt draaien - terwijl dat geheugen er toch bij elk .Net app in de taskmon bijgeteld wordt.

Aha, ook tussen VM instanties? Kijk, dat wist ik niet. Toch nog wat geleerd. Ik besteedde overigens bewust geen verdere aandacht aan de Taskmanager memory footprint. Hier werd namelijk door whoami al iets over gezegd en dat werd ook al door de TS opgepakt.

Voutloos schreef op donderdag 12 juni 2008 @ 11:00:
[...]
Mijn opmerking gaat ook 100% op voor jouw post.
[...]

En ik behandel niemand als kleuter.

Wijsneus Uit verband rukken van onderdelen van mijn posts he?

[Voutloos]

offtopic:
Nee, de opbouw van jouw post komt gewoon compleet overeen met die van anderen uit het topic, behalve dan dat je aangeeft verbaasd te zijn van de 10 MB. Je zou het zelfs gewoon een dubbelpost kunnen noemen. Maar goed, ik stop hiermee, want we zijn het over de essentie gewoon eens.

[Verwijderd]

Als de tijd verstreken is toont het tooltje een venster (form) met een countdown en een "Uitstellen" knop waarmee de uitvoering van het afsluiten geannuleerd wordt. Kan ik zoiets dan ook bereiken zonder Windows Forms? De executable zelf is 21Kb groot, en het aangegeven RAM-geheugen komt van de release-versie.

Ik begrijp dat het .Net framework nogal wat overhead heeft (spijtig genoeg zoals wel meer MS-producten, maar laten we daar geen discussie over beginnen), maar het is gewoon een makkelijke manier om alles op een makkelijke manier voor elkaar te krijgen.

@unclero: De uitvoeringstijd duurt dan ook wel de volledige tijd dat het systeem up-time is. Het tooltje checkt ook elke minuut of 'het tijd is'.

@Raven: Direct Message staat aan

Ik begrijp dat het moeilijk is om zoiets met een lage memory-footprint te bereiken in VB. Daarom besluit ik bij deze en tot mijn spijt om het toch maar zo te laten. Een cursus C++ zal iets te veel tijd in beslagnemen, en tijd is iets wat ik nu net niet heb (examens, webdesign ...). Jullie reacties hebben mij zeker veel bijgeleerd en als ik eens tijd heb zal ik de mogelijkheden van C++ e.d. bestuderen.

[roy-t]

bigbeng schreef op donderdag 12 juni 2008 @ 09:49:
Ik kan me voorstellen dat je schrikt van 10MB op iets wat niet veel meer is dan een batch-bestandje. Als je niet teveel van dit soort programma's hebt draaien is het niet een enorm probleem, 10MB is niet zoveel meer tegenwoordig. Mocht je er wel meerdere hebben draaien, dan zou je ook een service o.i.d. kunnen maken die verantwoordelijk is voor het afvuren van de diverse kleine assemblies. Voordeel is dat het dan binnen 1 runtime gebeurt, waardoor libraries maar 1x geladen worden. Daarmee beperk je in elk geval de overhead weer een beetje.

Maar ik zie dat je een form gebruikt. Is dat nodig? Kun je dit niet met een console app af?

offtopic:
Reacties dat 10MB in deze tijd niet veel is vind ik niet erg constructief. De topicstarter geeft aan dat hij 10MB veel vind vanwege de beperkte RAM beschikbaarheid op sommige PCs. Lijkt mij een valide argument, zeker omdat dit programma blijkbaar resident in het geheugen moet zitten. Om daar als argument tegenover te zetten dan 10MB niet veel is in deze tijd heeft dan weinig zin.

TS, heb jij tijd om je te verdiepen in andere programmeeromgevingen? Ik denk dat .NET iets teveel overhead heeft voor wat jij wil. Gezien de relatief simpele opzet van je programma komen zijn er geschikte talen, zoals C++, die naar native executables compileren.

Als het goed is / ik het goed heb (weet het niet 100%) zeker zijn die 10MB voor libs ook buiten deze applicatie/runtime te gebruiken. (als ik het echt goed heb draait er maar 1 runtime tegelijkertijd die alle .net programma's op dat moment afhandelt, en ook maar 1x de libs laat dus op die manier).

Dus dan zouden meerdere programma's het juist efficienter maken cq. het tweede programma zou dan nog slechts 1MB nodig hebben of 5MB per programma als je het zo wilt zien. Een service maken zou dan overbodig zijn, maar helemaal zeker weten doe ik het niet.

[unclero]

Verwijderd schreef op donderdag 12 juni 2008 @ 12:58:
@unclero: De uitvoeringstijd duurt dan ook wel de volledige tijd dat het systeem up-time is. Het tooltje checkt ook elke minuut of 'het tijd is'.

Ahh..

In mijn oplossing wordt ie pas aangeroepen als het nodig is (in dit geval om het uur, maar das in te stellen ).

[Verwijderd]

@Unclero: Hoe roep jij het dan precies aan? Via geplande taken? Bij mij gebeurt de aanroep via het 1e form (start.vb) die, als het tijd is, het 2e form (main.vb) start die het eigenlijke afsluiten afhandelt (zie code op 1e pagina).

[unclero]

Verwijderd schreef op donderdag 12 juni 2008 @ 13:29:
@Unclero: Hoe roep jij het dan precies aan? Via geplande taken? Bij mij gebeurt de aanroep via het 1e form (start.vb) die, als het tijd is, het 2e form (main.vb) start die het eigenlijke afsluiten afhandelt (zie code op 1e pagina).

Het maakt onderdeel uit van een netwerksoftwarepakket voor het MKB waar ik in me vrije tijd mee bezig ben.
Komt er op neer dat bijv bij het opstarten, en om het uur, en om middernacht, en tijdens de lunchpauze, bepaalde collecties batchfiletjes worden gestart die allerlei taken uitvoeren. (backuppen, updaten, enzovoorts)
Draait idd voor een deel via Scheduled Tasks.

[Brahiewahiewa]

Beetje onzinnig om een zelfgemaakt form te gebruiken voor het "aftellen". De standaardfunctionaliteit van Windows (die ook door shutdown.exe gebruikt wordt) doet dit ook.

Verder is het veel beter om het proces vanaf te server te initiëren. Als er een paar honderd clients elke minuut dat filetje staan te pollen, kan je server het al lelijk druk krijgen. 't Is veel eleganter om dat event based te doen. In z'n simpelste vorm:

AT 16:35 /every:mon,tue,wed,thu,fri for %F in (bestandjemetcomputernamen.txt) do shutdown /m \\%f /t 10 /c "Uw compu wordt afgesloten"

[.oisyn]

Verwijderd schreef op donderdag 12 juni 2008 @ 12:58:
Ik begrijp dat het .Net framework nogal wat overhead heeft (spijtig genoeg zoals wel meer MS-producten, maar laten we daar geen discussie over beginnen)

Dat is inherent aan het hebben van een VM, waarvoor jij hebt gekozen toen je dit tooltje ging maken. Daar dus MS maar de schuld van geven is een beetje hypocriet. Waarom denk je dat Java hetzelfde 'probleem' heeft? Niet omdat ze bij Sun net zulke "prutsers" zijn als bij MS oid.

[ Voor 11% gewijzigd door .oisyn op 12-06-2008 14:46 ]

[Verwijderd]

Brahiewahiewa schreef op donderdag 12 juni 2008 @ 14:15:
Beetje onzinnig om een zelfgemaakt form te gebruiken voor het "aftellen". De standaardfunctionaliteit van Windows (die ook door shutdown.exe gebruikt wordt) doet dit ook.

Verder is het veel beter om het proces vanaf te server te initiëren. Als er een paar honderd clients elke minuut dat filetje staan te pollen, kan je server het al lelijk druk krijgen. 't Is veel eleganter om dat event based te doen. In z'n simpelste vorm:

AT 16:35 /every:mon,tue,wed,thu,fri for %F in (bestandjemetcomputernamen.txt) do shutdown /m \\%f /t 10 /c "Uw compu wordt afgesloten"

OK, maar dan kan ik toch niet gebruik maken van de "uitstellen"-knop? De gebruiker moet nog altijd een keuze krijgen.


@.oisyn: Ik weet uit ervaring dat er elegantere oplossingen zijn dan MS-producten, maar dit is zowat de eerste keer dat ik echt op de resources moet letten en schrok van de (erg hoge) 10MB. Ik denk dat mijn reactie wel gegrond is. Overigens heb ik er bijgezet dat ik er geen pro- en contra-MS discussie van wou maken. MS is helemaal geen slecht bedrijft, maar ik denk dat niemand met een onderbouwde reden kan beweren dat (sommige van) hun oplossingen GEEN performanceproblemen hebben ... Ik dacht dat het hoge geheugenverbruik met een simpele ingreep verholpen kon worden, wat dus niet het geval blijkt te zijn. Daarom ga ik in de toekomst (omdat ik nu geen tijd heb, lees mijn voorlaatste post) C++ bekijken.

EDIT @Brahiewahiewa: de file van de server streamen gebeurt om de 5 minuten, en aangezien het hier om een file gaat van 26 bytes*150 pc's moet de server 3,81 KB versturen in 5min, ik denk dat dit geen probleem vormt op een krachtige Dell PowerEdge server

[ Voor 7% gewijzigd door Verwijderd op 12-06-2008 15:23 ]

[.oisyn]

Verwijderd schreef op donderdag 12 juni 2008 @ 15:18:
@.oisyn: Ik weet uit ervaring dat er elegantere oplossingen zijn dan MS-producten

Ach kom nou. Ononderbouwde trolls, laat die alsjeblieft achterwege

maar dit is zowat de eerste keer dat ik echt op de resources moet letten en schrok van de (erg hoge) 10MB. Ik denk dat mijn reactie wel gegrond is. Overigens heb ik er bijgezet dat ik er geen pro- en contra-MS discussie van wou maken. MS is helemaal geen slecht bedrijft, maar ik denk dat niemand met een onderbouwde reden kan beweren dat (sommige van) hun oplossingen GEEN performanceproblemen hebben...

En dat geldt voor ieder bedrijf. Onzin dus om specifiek MS te noemen. En als je het hebt over .Net, kun je simpelweg niet verder van de waarheid zitten. Jij schrikt van die 10 MB, dat kan ik me voorstellen. Het is best veel voor een app die van zichzelf weinig doet, helemaal mee eens. Vervolgens geef je hier MS de schuld van, zonder dat je blijkbaar ook maar enigszins kennis hebt van de materie. Is het ook de schuld van Epic als ik de Unreal Engine gebruik om 1 simpel polygoon te renderen en dan blijkt dat m'n executable 15MB groot is?

Overigens heb ik er bijgezet dat ik er geen pro- en contra-MS discussie van wou maken

Dan moet je hier niet van die domme opmerkingen plaatsen, want dan vraag je er gewoon om

Ik dacht dat het hoge geheugenverbruik met een simpele ingreep verholpen kon worden, wat dus niet het geval blijkt te zijn. Daarom ga ik in de toekomst (omdat ik nu geen tijd heb, lees mijn voorlaatste post) C++ bekijken

Dan ga je zeker geen VC++ gebruiken, want ja, dat is ook een MS product... (en het feit dat een van de beste optimaliserende compilers is vergeten we voor het gemak dan maar even)

Kijk, ik ben het er helemaal mee eens dat MS niet altijd altebeste software heeft ontwikkeld. Maar WTFs kom je tegen in elk product van elke software ontwikkelaar, en MS is gewoon een heel erg groot softwarebedrijf dat heel erg veel software maakt en dus heel erg veel mensen in dienst heeft. Niet zo vreemd dat daar dus af en toe zooi uit komt. Maar dat argument kun jij niet zonder meer gebruiken om te zeggen dat "er elegantere oplossingen zijn dan MS-producten" (in sommige gevallen is dat waar, maar in heel veel gevallen ook weer niet), of het feit dat het MS' schuld is dat jouw applicatie veel geheugen gebruikt. Dat is namelijk niet hun schuld. Jij kiest (weliswaar niet bewust) voor een bepaalde oplossing (namelijk een hele virtual machine waarbinnen je applicatie moet draaien), en die oplossing is wellicht wat ongelukkig gekozen als je 10MB veel vindt (waarvan het meeste overigens in system resources gaat zitten die toch al zijn ingeladen, dus ik vraag me af hoeveel je applicatie daadwerkelijk aan extra geheugen inneemt, maar dat terzijde). Het schiet mij dus in het verkeerde keelgat dat je wel in staat bent om meteen met je vingertje te wijzen, zonder dat je daadwerkelijk snapt wat er ten grondslag ligt aan dat geheugengebruik, en daarbij voor het gemak ook maar even heel MS door het slijk haalt.

[ Voor 45% gewijzigd door .oisyn op 12-06-2008 16:12 ]

[.oisyn]

Heb net even een test gedaan met een redelijk simpele .Net applicatie, de MS Keyboard Layout Creator, en gekeken naar het geheugengebruik gerapporteerd door Process Explorer.

1 instantie gebruikt 21 MB. Daarvan is 7MB private en 14MB shareable, waarvan 3 MB daadwerkelijk geshared is.
Nog een instantie opgestart. Zelfde geheugengebruik. Maar nu wordt de volle 14MB van beide processen geshared volgens Process Explorer, terwijl taskmon voor beide processen doodleuk 21MB per stuk rapporteert.

Nou weet ik niet of op dat systeem waar jouw applicatie op moet draaien ook andere .Net software draait, maar het is wellicht handig om even te kijken naar hoeveel er daadwerkelijk in gebruik is.
Process Explorer (dubbelklikken op het proces in kwestie en dan naar de performance tab gaan, onder het stukje physical memory)

[ZaZ]

Zo ga ik elke dag met mijn Hummer naar de brievenbus aan het einde van de straat (pakweg 100 meter)
Maar een brandstof dat het me kost! Die prutsers daar begrijpen niets van auto's bouwen!
Ik ga een Smart kopen. Kan ik ook van de zomer lekker off-road mee gaan tuffen hoop ik

[Verwijderd]

Ik heb je testje ook gedaan, en ik kom op volgende waardes:

- Working set: 10412K
- WS Private: 1912K
- WS Shareable: 8500K
- WS Shared: 4492K
- Peak Working set: 10412K

Als ik een 2e instantie start, stijgt de WS-shared waarde tot bijna de WS-Shareable waarde. Als ik het goed begrijp worden de libraries dan inderdaad gedeeld. Ik heb besloten dat ik vrede ga nemen met het 10MB geheugengebruik.

Verder wou ik mij nog even excuseren voor mijn blijkbaar te contra-MS reactie. Ik begrijp dat hier een opmerking op gegeven wordt, maar natuurlijk is het absoluut niet de bedoeling om hier een discussie te starten tussen MS-fans en niet-MS-fans. Uiteraard zijn "Niet alle MS-producten" slecht, maar voor sommige MS-producten zijn er soms betere alternatieven beschikbaar. Het is helemaal niet de bedoeling om MS te blaimen, maar het is heel normaal dat MS niet de beste producten op alle mogelijke markten kan leveren (en sommige MS-producten gebruik ik dagelijks met plezier).

[? ?]

..

[ Voor 103% gewijzigd door ? ? op 25-01-2013 09:51 ]

[RayNbow]

Verwijderd schreef op donderdag 12 juni 2008 @ 16:45:
Ik heb besloten dat ik vrede ga nemen met het 10MB geheugengebruik.

Nog een "trucje" om Taskman te misleiden. Houd Taskman geopend, start je .NET executable en minimize, restore, minimize, restore, ..., minimize hem eens een paar keer. Valt er iets op aan het geheugengebruik?