Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When define __CONSTRAINED__ , client get message 12ms slower. #124

Open
x44yz opened this issue May 22, 2019 · 1 comment
Open

When define __CONSTRAINED__ , client get message 12ms slower. #124

x44yz opened this issue May 22, 2019 · 1 comment

Comments

@x44yz
Copy link

x44yz commented May 22, 2019

Hello.
Please forgive me for my poor English.

I create a simple ping-pong test project ( after host and client create connect, client send a empty message to host, when host got message then send a empty message back to client).
If undefine __CONSTRAINED, the duration is 3ms.
When define __CONSTRAINED, the duration is 15-17ms.

I am wondering why the delay is so big when __CONSTRAINED.
Any help is appreciated, Thanks.

@lodicolo
Copy link

lodicolo commented Jul 31, 2020

I am also seeing this, but based on the code that gets compiled when __CONSTRAINED__ is specified I do not understand how it can be so much slower.

Running the Win32 variant vs __CONSTRAINED__ variants of the platform-specific NetUtility/NetTime functions through a tight-loop with a stopwatch, I would expect (if it actually the difference) Win32 to be much faster, but it's actually orders of magnitude slower on half the functions.

None of the functions show up as big red flags in a CPU profile either.

Edit: So just by copying code from PlatformConstrained to PlatformWin32 I discovered that it seems like Environment.TickCount is what is slowing it down. I do not notice this in tight-loop timing tests (it's actually twice as fast as Stopwatch.GetTimestamp()) but for whatever reason it does appear when actually sending messages. I do not know why Stopwatch.GetTimestamp() isn't being used, but in my fork I changed the Environment.TickCount (which is actually milliseconds) to DateTime.UtcNow.Ticks (which is actually ticks, so I also had to convert it to the desired units with the TimeSpan.TicksPer* constants) and it appears to have mostly resolved the time issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants