0

I just installed dot tracer to monitor a huge self-service kiosk manager app that I wrote and now am working on it's performance issues. The solution consists of nearly 40 different projects which are loaded (depending on the requirements of the customer) by the main assembly which is a WPF executable using reflection in run-time.

The performance is quite acceptable on a 3 GHz machine with 3 GBs of RAM and a graphic card (6% - 12% of CPU usage, 80 MBs of RAM and 20% - 40% of GPU usage) but 3 days ago I ran it on a very weak machine (0.6 GHz CPU, 1 GB of RAM and no Graphic card) of one of the clients and the CPU usage was above 60%, so it hit me to go find what was the bottleneck! Anyway, dot tracer shows me that most of the time is spent on waiting (mostly Thread.Sleep sections) because my app has different threads that wait in some loops for something (i.e. an incoming message on a socket, a key press on a device, etc.) to happen.

So, is it bad that my app is using Thread.Sleep()? Do I have any other choices?

Here is the test result : enter image description here

Arashv
  • 305
  • 4
  • 15
  • Run your profiler again. Sleeps won't hit your CPU to 60% (unless your threads sleep very very often and so short that only spinning is performed but...this is seldom the case unless you're processing almost real time data). BTW it just means that that function executes very often (during profiling sampling), it doesn't mean it uses a lot of CPU. – Adriano Repetti Nov 26 '13 at 13:23
  • In fact sleep should reduce the CPU, what makes you think it consumes CPU? Sidenote:use signaling using eventwaithandles don't sleep. – Sriram Sakthivel Nov 26 '13 at 13:25
  • Isn't this CPU usage related to drawing/building GUI? Get so weak machine as the client's one and profile it there. – Konrad Kokosa Nov 26 '13 at 13:33
  • @Adriano The main Structure of the threads using sleep is like `while(flag){/*Do some work*/ Thread.Sleep(1000);} does it help to diagnose the cause of the problem? Is it considered "very often" from your point of view or not? – Arashv Nov 26 '13 at 13:35
  • @SriramSakthivel I completely agree with you on the subject, I think Thread.Sleep() should reduce CPU usage of the thread calling it, but dottracer keeps marking these threads and function calls red. Any idea why? – Arashv Nov 26 '13 at 13:37
  • @KonradKokosa As you can see in the picture at least it doesn't look that way – Arashv Nov 26 '13 at 13:37
  • @Arashv May be that means that method takes xyz time to complete? which may be huge.. – Sriram Sakthivel Nov 26 '13 at 13:38
  • @SriramSakthivel So if that's huge, what is the solution? How can I minimize it? – Arashv Nov 26 '13 at 13:48
  • No, it's not a case I would consider "very often". But...think about what profiler did: just **sampled** which function is executing each XYZ milliseconds. a Thread.Sleep(1000) will hit very often (even if thread is just sleeping then using 0% CPU). It doesn't mean it consumes CPU. How to minimize? We can't say because we don't know your code, profiling should be used a start point but _cum grano salis_. I would suggest to simply ignore Thread.Sleep() because it doesn't consume CPU and go on with **next function in the list**! – Adriano Repetti Nov 26 '13 at 13:51
  • @Arashv All I can say is you're looking in a wrong direction. Sleep is not at all a problem. It may freeze the app if `Sleep` in UI thread, but that won't consume CPU – Sriram Sakthivel Nov 26 '13 at 13:53
  • Hence, as I said, get weak machine and profile it there. – Konrad Kokosa Nov 26 '13 at 14:47
  • Why are you using Thread.Sleep() , what is your usage scenario since u have a lot of them? Have you tried using workflow or state machine patterns to avoid Thread.Sleep() ? – Inga Nov 26 '13 at 22:43
  • 1
    @Adriano You were right pal. dottracer just samples the execution flow and tells you which functions got called more often, so it wasn't suggesting that performance was bad. – Arashv Dec 01 '13 at 18:17
  • But the benefit I got from dottracer was that I accidentally discovered and fixed some memory leaks of WPF sections of the app as @KonradKokosa was suspicious about. – Arashv Dec 01 '13 at 18:20

0 Answers0