|
|
You should use Stopwatch.StartNew() and then the Elapsed.TotalMilliseconds property for measuring the time. Using the common system clock may lead to wrong values.
|
|
|
|
|
Add use StopWatch, result not change,
|
|
|
|
|
The answer is in the documentation.
try
{
tc.GetStream().Read(b, 0, 1);
}
Look up TcpClient on MSDN. GetStream method does not throw any IOException, so must be the read-method. And yes, MSDN states[^] that an IOException is thrown when:
"The underlying Socket is closed."
Suggestion: open the socket. That might also give a timeout, but a connection-timeout. You should also test for all the exceptions mentioned in the documentation that I pointed to, as it may throw more than IOExceptions if implemented correctly.
Also, ticks aren't updated every ms, so that makes it useless for timing thight code
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
Congrats on repeating.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The process of "handling an exception" is "expensive" (compute-wise).
It involves "unwinding the stack", etc. ... all of which incurs "overhead" that one normally does not encounter if one simply ignored the exception (somehow).
Your objective should be to eliminate or reduce the number of exceptions instead of worrying about the "duration" of an exception.
(Maybe perform I/O on another thread if the "real" issue is UI performance).
|
|
|
|
|
Gerry Schmitz wrote: The process of "handling an exception" is "expensive" (compute-wise). No, it is not.
Give it a try in a console-app without the debugger attached.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Ok, yours are cheap; the ones I encounter (in my non-console apps), tend to be expensive.
My bad for generalizing.
|
|
|
|
|
Unless a debugger is attached, throwing an exception is not an "expensive" instruction.
Gerry Schmitz wrote: in my non-console apps Use the exact same infrastructure, and the same applies.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
In my world (kiosks), anything approaching 100ms is "expensive".
|
|
|
|
|
Expensive compared to which other technique?
Checking if your primary key-field is in the database before doing the insert? Checking if you still have all write permission before doing an update?
--edit
If handling one took 100ms, you'd only be able to throw and handle 10. You can throw (and handle) some thousand exceptions in a second.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
modified 18-Sep-16 8:03am.
|
|
|
|
|
"Expensive" in terms of response time for the user.
(Felt it necessary to add some "data base" nonsense?)
A "thousand exceptions per second" and no impact?
That one is easy to prove.
Just try a couple of combinations of .Parse (with / without exception handling; with and without a valid string). No debugger.
Must be an "anomaly"; Or doesn't that fit your "pattern"?
|
|
|
|
|
Gerry Schmitz wrote: "Expensive" in terms of response time for the user. Expensive is in terms of CPU cost.
Gerry Schmitz wrote: (Felt it necessary to add some "data base" nonsense?) No, just pointing out that catching the exception is usually less expensive than doing a check. Same pattern applies to files, connections etc
Gerry Schmitz wrote: Just try a couple of combinations of .Parse (with / without exception handling; with and without a valid string). No debugger. Yes, parsing is expensive. Throwing exceptions is not.
You're welcome
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
No idea what that means, but here[^] you can copy/paste and see for yourself
50k exceptions in a second. Your definition of "expensive" may vary from mine, ofc.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Exception is Expensive I agree.
But tested in console application on i7 processor, and time 500ms?
It seems to me this is some delay.
|
|
|
|
|
There's also a "timeout" on NetworkStream.
I don't know if it has any relation to the timeout on TcpClient.
|
|
|
|
|
ReadTimeout NetStream returned GetStream() is same as TCPClient.ReceiveTimeout
|
|
|
|
|
Did you time the GetStream() separate from the Read()?
|
|
|
|
|
I tried it's, but time not changed.
|
|
|
|
|
Well, which took longer? The GetStream() or the Read() ... or you don't understand what I'm talking about.
|
|
|
|
|
GetStream() 0ms
Read() 530ms
|
|
|
|
|
Message Closed
modified 9-Sep-16 16:38pm.
|
|
|
|
|
This is a test of the CP Forum posting system. If this were an actual posting, it would include useful content and might provide some context for a question.
Seriously though, I'm not going to click your link. Please explain what you need assistance with in as much detail as you can provide.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|