Quantcast
Channel: Questions in topic: "dll"
Viewing all articles
Browse latest Browse all 706

What could cause C++ dll muti-threading to perform worse in Build mode

$
0
0
I am writing a C++ DLL for my Unity Windows application, where the dll will create multiple work-intense and time-critical threads. One surprising behaviour I observed was that the performance of the DLL was significantly worse in **Build** mode than **Editor** mode. To rule out the possibility that my function is affecting the performance, I did an experiment where I replaced my function with `std::this_thread::sleep_for(std::chrono::milliseconds(30))` and logged down the execution time. When in the Editor mode, the execution time was very consistently around 30 *ms* as expected. I ran the editor session for a long time to make sure the time measurement is consistent. However, when in the Build, I could always observe some sort of "hiccup" from time to time that the abnormal execution time can range from 35 ms to 45 ms. I allocated a console window to display the standard output from the DLL in both Editor and Build mode. Here is the pseudo code of my DLL: void initialize(std::thread *& pWorkerThread, [other_args]) { pWorkerThread = new std::thread(WorkerFunction); // Initialize other threads ... } void stop(std::thread *& pWorkerThread, [other_args]) { // set stop_condition here if (pWorkerThread->joinable()) { pWorkerThread->join(); } delete pWorkerThread; pWorkerThread = NULL; } void WorkerFunction() { while (!stop_condition) { std::chrono::steady_clock::time_point t_start = std::chrono::steady_clock::now(); // simulate the work load std::this_thread::sleep_for(std::chrono::milliseconds(30)); std::chrono::steady_clock::time_point t_end = std::chrono::steady_clock::now(); std::chrono::duration dur = t_end - t_start; std::cout << "Process duration: " << dur.count() << std::endl; } } Since the editor is adding a lot of overhead, one would typically assume the performance is worse in Editor mode. In addition, since my c++ functions are built into the DLL, based on my understanding, they should behave the same regardless of which mode my Unity application calls them. I was suspecting the process and thread priority might be different in Build mode, so I manually set the priority class of my application to High_PRIORITY_CLASS using WinAPI, but it did not improve the situation at all. At this point, I have been stuck on this for days and I am running out of ideas for how this could happen and what to do. If someone could point out potential topics I should look at, or explain what are the differences between build and editor mode that could result in such performance issue, I would greatly appreciate it!

Viewing all articles
Browse latest Browse all 706

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>