Extremally bad performance on WPF if logging not configured

[antonGritsenko]

I've faced with very weird behavior of the TDLib under Windows WPF: if logging not configured (so neither SetLogVerbosityLevel or SetLogStream was called) then TDLib works extremely slow. The connection phase (stateConnecting -> stateReady) taking about 2-3 minutes, getting chats - about 3 minutes, and so on. Every communication with the TDLib takes ages.

I took this as the source https://github.com/tdlib/td/blob/master/example/csharp/TdExample.cs, move it to the WPF (use Forms instead Console.ReadLine) and removed https://github.com/tdlib/td/blob/master/example/csharp/TdExample.cs#L214-L218 Expected result: phone number requested after few seconds Actual result Phone number requested after about 2 minutes

All events are super slow. The app itself not freezed, I see events in the debug output, they all just have a huge delay. As soon as SetLogVerbosityLevel OR SetLogStream (so even SetLogStream is enough) called the app start working as expected.

Seems issue occurred because TDLib can't find the stdout under WPF (just a guess).

Also TDSharp is affected by this https://github.com/egramtel/tdsharp/issues/109

[levlam]

This is expected behavior if stderr is slow. Therefore, the first thing that done in the example is logging set up, which also should be the first thing to do in other TDLib usages.

[ForNeVeR]

In a program compiled with Windows subsystem, stderr is not slow. It is non-existent. So, it would be interesting to see what td uses for logging in this situation. Perhaps we may improve it significantly by checking if stderr is closed.

[levlam]

So, it would be interesting to see what td uses for logging in this situation.

The log is written to NUL by default in the case of UWP. Otherwise, it is up to Windows to handle writes to GetStdHandle(STD_ERROR_HANDLE).

[antonGritsenko]

WPF is "a bit" different than UWP. GetStdHandle under WPF return null as pointer to STD_ERR.