Strange problem with a VCL app and several threads, sometimes running the exe (outside the ide) goes "random sluggish" (not smooth speed). More frequent in 32bit than 64bit. Sometimes it justs runs fine, same code same tests. When changing process priority at task manager, sometimes the problem is fixed (ie: to "above normal" to "normal" again). Its puzzling !
Post example code.
ReplyDeleteWhat does task manager say about CPU used when it becomes sluggish?
ReplyDeleteAre you using Synchronize? You'd better avoid it because it actually defeat multithreading.
CPU is quite constant (37%) because rest of time is GPU (opengl). No synchronize, just WaitFor several threads. Hard to create a small reproduceable code. Funny thing is sometimes it works smooth, endless loop very perfect smooth.
ReplyDeleteI've uploaded 32/64bit exes here:
http://www.steema.us/files/vcl/public/TeeChart2014/Examples/TeeChart_FastLine_Speed_multi-cpu.zip
Calling Application.ProcessMessages from TThread.Synchronize sticks out as a possible bomb.
ReplyDeleteWithout calling App.PM, it starts "slow" and then after some seconds it goes to full speed (ok), but as the thread loop is so busy, the main UI is not responsive.
ReplyDeleteI'll try to fix this now, maybe calling App.PM less times than before. Calling Sleep(xx) in thread Execute does not help.
You CANNOT call Application.ProcessMessages from a thread. If for some reason you need a message pump in your thread, you must create it using Windows API, not Delphi runtime.
ReplyDeleteDo not call TThread.WaitFor if you want your application to be responsive. WaitFor because it calls MsgWaitForMultipleObjects passing SQ_SENDMESSAGE. You need QS_ALLEVENTS to have the application really responding.
You should rewrite your application so that WaitFor is not needed. When the main thread has to wait for a thread, use a Windows event (or other Windows synchronization object) and call MsgWaitForMultipleObjects passing QS_ALLEVENTS. The API function will return when message has to be processed and you can then call Processmessages.
François Piette I'll verify what I think its happening, 10 threads are created,run,free 200 times per second, inside a synchronize from another global thread. The main ui is never catching up and for some reason all slows down. When calling app.pm less times (just 20 per second) all is great and responsive. The problem I think is the busy busy loop starts at form show event and it should start at app onidle, or somewhen after ui is complete.
ReplyDeleteCreating 200 threads per second and destroying as much is not the best idea. You should have a pool of threads and reuse the threads again and again.
ReplyDelete