Es ist nicht meine App, habe nur den Optimierungsauftrag bekommen. So wie es sehe wurde in alter Version ein TTimer verwendet um mehrere Werte per
WMI zu holen, welche dem User angezeigt werden. Hier trat das Problem auf, dass 30-50% jeder Sekunde der Message Queue von dem
Query gelockt wird (Callback?). Das Fenster hängt. Deshalb wurde das ganze in einen TThread verschoben. Der
Query blockiert aber den Message Queue auch im Thread, nur nicht ganz so schlimm wie in einem TTimer. Der Thread macht ja schon Sinn, weil jede Sekunde die Werte neu ausgelesen werden.
Heute habe ich Tests mit der Powershell gemacht (Get-CimInstance -Class Win32_PerfRawData_Counters_ProcessorInformation). Dort ist auch alles arschlahm.
WMI scheint totaler Müll zu sein!
>Was erwartest du von dem AND in wbemFlagReturnImmediately and wbemFlagForwardOnly ?
Ist nicht mein Code. Ich weiß nicht was hier gemacht wird. Laut MS Docs wird so ein Semisynchronous Call erzeugt, der auch schneller sein sollte.
>Und was willst du mit der CPU-Geschwindigkeit?
>Eventuell gibt es was Besseres, für deinen Anwendungsfall.
>GetProcessTimes,
MSDN-Library durchsuchenGetSystemTimes, PerformenceCounters usw.
Diese wird erstmals angezeigt. Funktioniert nur richtig wenn der PC nicht übertaktet wird (sonst aber keine andere Möglichkeit den Wert zu bekommen ohne einen sys Treiber).
Dann kann der User noch konditionell Scripte starten wenn die Last gering ist. Deshalb braucht man den Takt, CPU Usage reicht alleine nicht aus.
Zitat
Baum-Darstellung
