we wrote our own server software for a client.
It runs and provides a JSON based API via Serversocket from a console app to query database and have some logic in the server app.
Basically it runs a loop with DoEvents as the main loop:
do
DoEvents 10
loop until ende
This loop takes 0.2% CPU time in Xojo 2014r2 and 99% in 2018r1. Mac and Linux, 32 or 64bit doesn’t matter.
Works fine in 2018r1, but as soon as we initialize the thread pool code used (From RBLibrary years ago), you can see CPU time going up.
Anyone has an idea what that could be?
It has to be something in your threads. A simple test here with only the Run event loop executing from a console app built using 2012r2.1, 2016r4, 2017r3, and 2018r1 result in the same 0.3% CPU on a single core here.
Our middleware server has at least two threads that are started before the DoEvents loop that keep running through the life of the server. Again, though, I checked on my Mac while our production platform is Linux.
(I just realized that I last compiled with something, er, newer than 2018r1. Have you tried that?)
in the lower portion of ThreadPoolManager.Run always be ignored/skipped as other threads are running? This will cause the loop its in to run at full speed which causes 100% CPU usage on the logical processor. I have no idea why this is different to the old version, maybe they fixed something? If you set that True to False it runs as expected with minimal CPU usage (windows 10).
There’s a noticeable difference in performance between 2014r2 and 2018r1 in Windows, I couldn’t call it a 2% to 99% difference though, more like 50% to 90%. The difference might just be optimisations in the compiler causing a faster loop and thus more CPU usage.
Well, we switch between delay 0 and 1 there. 0 when busy, 1 when not.
But still I think there is a bug in the thread handling.
If a thread called sleep(1, true) and nothing else is to be done, Xojo doesn’t do the 1ms pause.
[quote=386952:@Christian Schmitz]Well, we switch between delay 0 and 1 there. 0 when busy, 1 when not.
But still I think there is a bug in the thread handling.
If a thread called sleep(1, true) and nothing else is to be done, Xojo doesn’t do the 1ms pause.[/quote]
i notice if i use 5ms instead of 1ms then it’s all back to normal. (tested macos xojo 2018r1)
sleep 1ms = 99.6% cpu on 32-bit
sleep 2ms = 33.7% cpu on 32-bit
sleep 5ms = 3.2%-5.6% cpu on 32-bit
sleep 1ms = 99.7% cpu on 64-bit
sleep 2ms = 35.9%-36.9% cpu on 64-bit
sleep 5ms = 3.29% cpu on 64-bit
so it’s about the same as it ever was, as i don’t see negative change if we say App.DoEvents( [ms] ) is the same as Sleep( [ms] ).
Perhaps 1ms is just too much overhead (fast switching)? I’ve just never used it as it proved the processing power it uses is having overhead due to some context switching being too fast, at least i must have read that somewhere in the past.
usually if i use any kind of sleep i never go lower than 2ms on a mac an no lower than 5ms on windows.
