brandelh hat geschrieben:ich kann dir zwar nicht mehr ganz folgen, aber wie sollte DIES durch eine zweite CPU im Programm selbst verbessert werden ?
naja ... nicht jedes OCX / DLL ist "MT unfähig" ... diese Beschränkung kommt IMHO von Xbase++
die PostgreSQL "libpq.dll" ist ja Thread fähig und ich könnte eine "eigene" Connection pro Thread haben ...
wenn ich nun pro Thread eine CPU hätte könnte man auch grosse Resultset bearbeiten, wie ich es mit SQL vorhabe, ohne Performance Einbussen auf anderen Threads / CPUs.
brandelh hat geschrieben:Ich vermute eher, dass XbpActiveXControl() sagen wir mal "umständlicher" implementiert wurde und daher langsamer arbeitet als bei Harbour.
ich kann ja statt dessen Disp_HPR.DLL nehmen und es mit Xbase++ ODER harbour verwenden.
wenn also Disp_HPR.DLL als "Konstante" gilt liegt der Geschwindigkeits-Unterschiede bei der Appplikation welche die DLL anspricht.
***
... nur wie schon gesagt, geht es mir in diesem Thread nicht um "Power" sondern um "ECO"
ich habe mal 3 Demos gemacht die das verdeutlichen sollen.
1.) morecpu1.exe : kein Thread, alles wie gewohnt auf CPU 1
2.) morecpu2.exe : kein Thread, schaltet aber jedes mal auf eine CPU (random)
3.) morecpu3.exe : mit Thread, schaltet mit o:setInterval(10) ständig um
wenn ihr die Demos starte im Taskmanager ansehen was die CPUs machen.
wer "mehr Belastung" benötigt starte mit (irgendeinem) Parameter AUSSER "1"
Resultat "Lüfter" :
bei 1.) springt der Lüfter nach kurzer Zeit an
bei 2.) springt der Lüfter "ab-und-zu" an wenn es "länger dauert" und er (noch) mehr Power benötigt
bei 3.) springt der Lüfter so gut wie nie an
p.s. ich habe die GRA Ausgabe nicht gemessen d.h. ich weiss nicht ob 3.) "langsamer" ist als 1.) oder 2.) ist ... ist eh "sehr langsam" mit Xbase++ GRA ...