Closed chergert closed 2 months ago
Looking at CountdownEvent, and assuming it's a fairly straightforward implementation of the C# equivalent, I see it doing ResetEvent()
in the AddCount()
case.
Shouldn't it never need to reset when adding, only potentially when signalling?
@chergert thank you for having a look at that.
not sure why it was implemented that way (older than my affiliation with the project) but the condition could at least be improved to only reset when countdonw->count == 0
before adding.
Describe the bug
I'm doing some performance profiling of the FreeRDP support in GNOME 47 via
gnome-remote-desktop
using what will become Fedora 41. I notice thatlibfreerdp3.so
is spending considerable time inwinpr_SubmitThreadPoolWork()
(on the machine hosting the session).Having spent considerable time in my early career working on Mono and various runtime primitives, I can empathize with the amount of effort it takes to manage the scale of abstractions in
winpr
.Specifically:
CountdownEvent_AddCount()
, about half isQueue_Enqueue()
eventfd_read()
andeventfd_write()
Expected behavior I'd expect the overhead of submitting threadpool work to be in the .01-.05% overhead range. Just roughly basing that on other threadpools I've written w/ semaphores to flag workers (which is what looks like is going on here) and profiling them for comparison.
Application details
FreeRDP version: freerdp-libs-3.7.0-1.fc41.x86_64
Output of
xfreerdp /buildconfig