locked
threadpool::RunAsync(), workItem running very slow

    Question

  • Hi,

    I'm porting an existing c++ win32 application to windows store (c++/cx). I've put things that was previously done in a native separated thread into an unique async work item given to the ThreadPool.

    here is the pseudo-code of the encapsulated lambda runned by the work item :

    auto lambdaFunc = [&](IAsyncAction^ pItem)
    {
        while(!bExit)
        {
            doSoWork();
            waitNewWork();
        }
    };

    WorkItemHandler^ pItemHandler = ref new WorkItemHandler(lambdaFunc);
    ThreadPoll::RunAsync(pItemHandler, WorkItemPriority::High);

    the waitNewWork() rely on an event signaled by the main thread, when new job could be treated by the workItem.

    As a result, I get very poor performances on the winStore app, about 6-7x slower than the same application running under native win32 desktop.
    I've made a Concurrency Visualizer capture and I've observed that most of a time, all worker threads are doing nothing but wait.

    Am I doing something wrong with the threadpool ? Maybe having an evet wait cause the threadPool thinking the work item has low priority or finished its job and so it schedule it too much time after the event is signaled ?

    Any help appreciated. Thanks.

    Monday, April 29, 2013 1:42 PM

Answers

  • I already tried this option too withot seeing any change.

    But actually, I've found what goes wrong with my app, this wasn't because of the threadpool.
    (I had some code dependent of the framerate, which is locked to 60fps on windows store while on win32 it runs to about 400 fps ;) )

    • Marked as answer by DZ433 Thursday, May 2, 2013 8:14 AM
    Thursday, May 2, 2013 8:14 AM

All replies

  • I have something similar in my app (Win32 code that's in a Wait loop in a thread waiting for things to do) and I haven't noticed any performance issues. One thing I do differently is to add the TimeSliced flag to my RunAsync call:

      auto workItemHandlerX   = ref new WorkItemHandler( PollingThread );
      workItem = ThreadPool::RunAsync( workItemHandlerX, WorkItemPriority::Low, WorkItemOptions::TimeSliced );
    
    I believe that adding the TimeSliced option makes the thread behave like a regular Win32 thread.

    See if that helps.

    Tuesday, April 30, 2013 12:19 AM
  • I already tried this option too withot seeing any change.

    But actually, I've found what goes wrong with my app, this wasn't because of the threadpool.
    (I had some code dependent of the framerate, which is locked to 60fps on windows store while on win32 it runs to about 400 fps ;) )

    • Marked as answer by DZ433 Thursday, May 2, 2013 8:14 AM
    Thursday, May 2, 2013 8:14 AM