High CPU usage under MS Windows

[Libsoup User <steergailn garrifulio mailexpire com>]

Hi there,

I have a performance problem porting a glib app to windows. This app
uses libsoup-2.4-1 to stream audio files on http. As soon as the
transfer begins, the CPU usage rises to 100%. It would return to 0%
when the transfer stops. The same application cost virtually nothing
CPU wise on Linux.

Basically the app does the following:
- instantiate a new soup server / register an handler / run server
async / run g_main_loop
- the handler sets message_body_set_accumulate to false, add some
fields to the http header and register 3 events with g_signal_connect
: "wrote_headers", "wrote_chunk", "finished".
- the signal handler for wrote_headers ant wrote_chunk reads a file up
until a predefined chunk size, set the body response with it and
finally calls soup_server_unpause_message.

I narrowed the problem down to NtWaitForMultipleObjects called by
g_poll in g_main_loop_run. This function is called almost 1 million
times per minute while transferring a file.
It has come to my attention that NtWaitForMultipleObjects is far more
expensive than its Unix counterpart 'select()'.

Enabling POLL DEBUG reveals the following that keeps repeating in the log :

polling context=0034C480 n=3 timeout=-1
g_poll: waiting for
 00001EE4
 00001EAC
 00001D24

  WaitForMultipleObjectsEx(3, 0)
  wait returns 2
  got event 00001D24
  WaitForMultipleObjectsEx(2, 0)
  wait returns 258 (WAIT_TIMEOUT)
g_main_poll(3) timeout: -1 - elapsed 0.0000000000 seconds
 [0x1d24 :
o
]


I could not identify where event 00001D24 is being created but knowing
it's a G_IO_OUT event, I highly suspect some code in soup-socket like
'soup_add_io_watch()' ?

While digging through the glib/libsoup source code, I saw that windows
is clearly a targeted OS. It's seems weird that such a basic scenario
could pose problem. Something must wrong in my application code but
what?

In the meantime, I registered a  "wrote-body-data" handler where I
force a Sleep(). That way the CPU usage drop down to 2% and music
plays without a glitch.