VB.NET hoge CPU load bij afronden

[Strunkie]

Hallo,

Ik ben bezig met een controller voor een machine maar ik loop tegen een rot probleem.
Ik krijg posities uit het apparaat als een Double getal deze wil ik graag afronden dus gebruik ik:

code:

Math.round(variable)

Wanneer ik dit doe krijg ik een CPU load van 1 CPU op 100%.
Als ik hem niet afrond heb ik een CPU load van 5%.

Hoe kan ik nog meer een double 30x per seconde afronden zonder zo'n achterlijk hoge CPU load?

Kiwie

[Woy]

Gaat er niet wat anders fout? Ik kan me niet voorstellen dat je van 30 maal afronden per seconden een dergelijk hoge load krijgt. Heb je niet per ongeluk een loop-conditie o.i.d. verkeerd staan.

[RobIII]

^ Wat hij zegt. Ik zou eerst eens met 100% zekerheid uitsluiten dat 't aan de Math.round zou liggen want ik geloof er geen zak van dat 30 doubles p/sec afronden 100% CPU load zou veroorzaken. Hell, ik zou 't nog niet geloven als 't 1% veroorzaakte. Zelfs niet op een 8088

[wvd_vegt]

Meestal het gevolg van in een lus zitten zonder het systeem/rest van de applicatie aan de beurt te laten.

[Strunkie]

[b][message=36668778,noline]
[...]

En dus niets van doen met een (of een paar) Math.round's per sec.
[...]

Zoals ik al zei: aan die Math.round ligt het écht niet. Heb je al eens gedebugged? Geprofiled? (Meten == weten). En heb je anders relevante(!) stukken code behalve de drie regels die je nu post?

Ik heb alle noteloze regels uit de timer gehaald dan hou ik dit deel over

code:

'Waardes uit driver halen
        XPS_C8.GroupPositionCurrentGet(SocketID, "Z", 1, grouppositionz)
        XPS_C8.GroupPositionCurrentGet(SocketID, "XY.X", 1, grouppositionx)
        XPS_C8.GroupPositionCurrentGet(SocketID, "XY.Y", 1, grouppositiony)

'afronden
        grouppositionz = Math.Round(grouppositionz)
        grouppositionx = Math.Round(grouppositionx)
        grouppositiony = Math.Round(grouppositiony)

[ Voor 60% gewijzigd door Strunkie op 29-08-2011 14:46 ]

[RobIII]

wvd_vegt schreef op maandag 29 augustus 2011 @ 14:39:
Meestal het gevolg van in een lus zitten zonder het systeem/rest van de applicatie aan de beurt te laten.

En dus niets van doen met een (of een paar) Math.round's per sec.

kiwie2 schreef op maandag 29 augustus 2011 @ 14:39:

Ik heb hem in een timergezet zodat ik hem sneller en langzamer kan laten resetten.
Als ik hem op 1 refresh per seconde zet heeft die ook zo'n achterlijke hoge load.

Zoals ik al zei: aan die Math.round ligt het écht niet. Heb je al eens gedebugged? Geprofiled? (Meten == weten). En heb je anders relevante(!) stukken code behalve de drie regels die je nu post?

Ter indicatie: in een simpele, net in elkaar geflanste, test doe ik er op mijn systeem 1.2 miljoen per seconde op 1 core.

[ Voor 7% gewijzigd door RobIII op 29-08-2011 14:46 ]

[Strunkie]

Edit: Niet van toepassing.
zie post 5e post

[ Voor 90% gewijzigd door Strunkie op 29-08-2011 14:50 ]

[RobIII]

kiwie2 schreef op maandag 29 augustus 2011 @ 14:47:
[...]


Mijn post komt van die van jou, doe ik goed, weet alleen niet hoe ik dat geflikt heb.

Uhh... sorry Hier kan ik even geen hout van snijden. Wat bedoel je?

kiwie2 schreef op maandag 29 augustus 2011 @ 14:47:
Edit: Niet van toepassing.
zie post 5e post

Wat doet die GroupPositionCurrentGet precies? Als die 6 regels 't enige zijn wat er in die timer gebeurt dan moet 't daar in zitten. Maar zoals ik al zei: heb je al geprofiled?

[ Voor 37% gewijzigd door RobIII op 29-08-2011 14:52 ]

[Mavamaarten]

Bij mijn testprogramma haal ik 1 359 275 afrondingen per seconde waarbij mijn CPU load rond de 30% blijft hangen. Ik snap echt niet hoe jij bij 30 per seconde zo veel CPU load krijgt. Er mòet echt gewoon iets anders fout zitten...

[Strunkie]

RobIII schreef op maandag 29 augustus 2011 @ 14:49:
[...]

Uhh... sorry Hier kan ik even geen hout van snijden. Wat bedoel je?


[...]

Wat doet die GroupPositionCurrentGet precies? Als die 6 regels 't enige zijn wat er in die timer gebeurt dan moet 't daar in zitten. Maar zoals ik al zei: heb je al geprofiled?

Ik ga even uitzoeken wat profiled betekend.
GroupPositionCurrentGet plaats een waarde in groupposition[as] als een double getal.
GroupPositionCurrentGet hoort bij een dll bestand.

[RobIII]

kiwie2 schreef op maandag 29 augustus 2011 @ 14:55:
[...]

Ik ga even uitzoeken wat profiled betekend.

Wikipedia: Profiling (computer programming)

kiwie2 schreef op maandag 29 augustus 2011 @ 14:55:
[...]
GroupPositionCurrentGet plaats een waarde in groupposition[as] als een double getal.
GroupPositionCurrentGet hoort bij een dll bestand.

en hoe weet je dat de load niet daardoor veroorzaakt wordt? Hoe heb je dat uitgesloten?
En zit 't niet gewoon in 't feit dat je (bijv) veel vaker je UI bijwerkt? Of een ander neveneffect van de wijzigingen die je steeds maakt?

[ Voor 4% gewijzigd door RobIII op 29-08-2011 15:01 ]

[Strunkie]

Dit is echt raar.
Het blijk een opsomming te zijn van een aantal dingen volgens mij.
Nu doet die het normaal met het verwijderen van de volgende code.

code:

        GPIO1DO_waardes = New BitArray(BitConverter.GetBytes(GPIO1DO_output))
        GPIO1DI_waardes = New BitArray(BitConverter.GetBytes(GPIO1DI_output))
        GPIO2DI_waardes = New BitArray(BitConverter.GetBytes(GPIO2DI_output))
        GPIO3DO_waardes = New BitArray(BitConverter.GetBytes(GPIO3DO_output))
        GPIO3DI_waardes = New BitArray(BitConverter.GetBytes(GPIO3DI_output))
        GPIO4DO_waardes = New BitArray(BitConverter.GetBytes(GPIO4DO_output))
        GPIO4DI_waardes = New BitArray(BitConverter.GetBytes(GPIO4DI_output))

        setGPIO1DO(GPIO1DO_waardes)
        setGPIO1DI(GPIO1DI_waardes)
        setGPIO2DI(GPIO2DI_waardes)
        setGPIO3DO(GPIO3DO_waardes)
        setGPIO3DI(GPIO3DI_waardes)
        setGPIO4DO(GPIO4DO_waardes)
        setGPIO4DI(GPIO4DI_waardes)

Op dit moment zit het programma op 5-15%
Balen aangezien die het soms niet goed doet en de andere keer wel

[RobIII]

Dus...er gebeurt veel meer in de timer tick event? Als je nou eens het complete verhaal vertelt i.p.v. flarden dan hoeven wij niet koffiedik te kijken.

Het kan nu vanalles zijn; ik weet niet wat dat GPIO ding precies is, maar als je heen-en-weer loopt te switchen tussen een COM component of die calls an sich zijn duur dan kan dat prima een oorzaak zijn. En voor 'tzelfde geld ligt het aan een UI die nu minder bijgewerkt wordt en dus minder aanslag op je CPU pleegt. Of...

[ Voor 50% gewijzigd door RobIII op 29-08-2011 15:09 ]

[Strunkie]

RobIII schreef op maandag 29 augustus 2011 @ 15:07:
Dus...er gebeurt veel meer in de timer tick event? Als je nou eens het complete verhaal vertelt i.p.v. flarden dan hoeven wij niet koffiedik te kijken.

Waarschijnlijk komt het omdat ik functions met een return had inplaats dat ik die hele return niet gebruikt.
Dit was een temp oplossing:

code:

Private Function setGPIO3DO(ByVal ba As BitArray) As String
        Dim sb As New System.Text.StringBuilder
        GPIO3do1.Checked = ba(0)
        GPIO3do2.Checked = ba(1)
        GPIO3do3.Checked = ba(2)
        GPIO3do4.Checked = ba(3)
        GPIO3do5.Checked = ba(4)
        GPIO3do6.Checked = ba(5)
        Return sb.ToString
    End Function

Dit heb ik nu veranderd naar:

code:

Private Sub setGPIO3DO(ByVal ba As BitArray)
        GPIO3do1.Checked = ba(0)
        GPIO3do2.Checked = ba(1)
        GPIO3do3.Checked = ba(2)
        GPIO3do4.Checked = ba(3)
        GPIO3do5.Checked = ba(4)
        GPIO3do6.Checked = ba(5)
    End Sub

Ik snap dat het maybe moeilijk te begrijpen is maar het is ook moeilijk uit te leggen als je niet je hele code kan/mag posten.

Oke er zit dus een memory leak in mijn thread omdat die te veel commando's over de socket heen stuurt.
Ik denk dat ik nu ECHT het probleem te pakken heb.

Iedereen bedankt ik denk dat ik er wel weer verder uit kan komen

[ Voor 13% gewijzigd door Strunkie op 29-08-2011 15:24 ]

[gorgi_19]

Dat mag geen zak uitmaken; zou me niets verbazen als die intern naar een string.empty als returnwaarde optimaliseert en dat het probleem zich later weer voordoet.

[Strunkie]

gorgi_19 schreef op maandag 29 augustus 2011 @ 15:25:
Dat mag geen zak uitmaken; zou me niets verbazen als die intern naar een string.empty als returnwaarde optimaliseert en dat het probleem zich later weer voordoet.

Het leek zo omdat tijdens de eerste debug de CPU laag bleef.
Na de 2e debug ronde schoot die weer terug naar 100%

In mijn thread stuurde die te veel commando's naar de controller.
Daar heb ik nu een pauze ingezet.

Ik weet het konden jullie nooit weten, maargoed als een persoon geen grote delen code mag plaatsen onstaan dit soort situaties in mijn ogen.
Het lijkt gefixt door een sleep in mijn thread van 100 miliseconde.

[RobIII]

kiwie2 schreef op maandag 29 augustus 2011 @ 15:31:

Ik weet het konden jullie nooit weten, maargoed als een persoon geen grote delen code mag plaatsen onstaan dit soort situaties in mijn ogen.

Met alle respect, maar dat ligt aan jouw (on)kunde in 't troubleshooten en probleembeschrijven, niet aan 't feit dat lappen code niet gepost mogen worden.
Alleen al het feit dat je Math.round de schuld geeft is een testament daarvan.

[ Voor 9% gewijzigd door RobIII op 29-08-2011 15:42 ]

[Creepy]

Je 100% usage komt door de communicatie met je apparaat. Je bent aan het wachten totdat de data verzonden is naar het apparaat of totdat je data terug hebt gekregen van het apparaat. Dat is wat je 100% CPU veroorzaakt. (IO wait). Dat heeft niks met return values of Math.round te maken. Als je een versimpeld stukje code had gegeven dat een compleet beeld had gegeven, dan was dat eerder op te vallen. Dat heeft niks met het niet mogen posten van lappen coden te maken. Als je aan het profilen was geslagen dan was je gelijk opgevallen welke delen van jouw code nu het meest tijd kosten, dan was ook gelijk opgevallen dat het de communicatie met je apparaat betrof. Dat afschuiven op het feit dat je geen lappen code mag posten is gewoon onzin. Wij zitten hier niet om jouw code te debuggen, we verwachten dat je dat in eerste instantie zelf doet. Dat heb je niet gedaan en daardoor trek je verkeerde conclusies (zoals dat Math.round de oorzaak is ).

[ Voor 17% gewijzigd door Creepy op 29-08-2011 16:06 ]