469,281 Members | 2,435 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,281 developers. It's quick & easy.

Thread Start Delay

Hello,

I have a problem with creation of new thread. The method .Start() of
newly created thread delays current thread for 0 - 1 second.
Cpu while delay occurs is about 5%.

Any idea?

Here is code used for measuring:

Thread t = new Thread(...);
DateTime dttt = DateTime.Now;
t.Start();
TimeSpan ts = DateTime.Now - dttt;
if (ts > new TimeSpan(0, 0, 0, 0, 20))
{
LogToScreen("!!!Thread Start Duration : " + ts.ToString());
}

Thanks for any advice.

Feb 2 '06 #1
37 7689
ales,

There is always going to be some overhead in starting up a thread. The
only way I can think of around this would be to create a task in the
ThreadPool which will start up the thread for you.

You might want to run some tests to determine how long that takes.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"ales" <al***********@logos.cz> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Hello,

I have a problem with creation of new thread. The method .Start() of
newly created thread delays current thread for 0 - 1 second.
Cpu while delay occurs is about 5%.

Any idea?

Here is code used for measuring:

Thread t = new Thread(...);
DateTime dttt = DateTime.Now;
t.Start();
TimeSpan ts = DateTime.Now - dttt;
if (ts > new TimeSpan(0, 0, 0, 0, 20))
{
LogToScreen("!!!Thread Start Duration : " + ts.ToString());
}

Thanks for any advice.

Feb 2 '06 #2
Thank you for answer, Nicholas. It could be solution, but I don't agree
there has to be one second overhead when there is nothing else
hapenning in the system. Something has to be wrong.

Feb 2 '06 #3
ales,
You either have more code going on that you haven't shown us, or there's
definitely something wrong. That if block should not be trigggered under the
conditions you describe. It just doesn't take that long to kick off a thread.

What is the method in the ellipses?

Thread t = new Thread(...);

?

Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"ales" wrote:
Thank you for answer, Nicholas. It could be solution, but I don't agree
there has to be one second overhead when there is nothing else
hapenning in the system. Something has to be wrong.

Feb 2 '06 #4
ales <al***********@logos.cz> wrote:
I have a problem with creation of new thread. The method .Start() of
newly created thread delays current thread for 0 - 1 second.
Cpu while delay occurs is about 5%.

Any idea?

Here is code used for measuring:

Thread t = new Thread(...);
DateTime dttt = DateTime.Now;
t.Start();
TimeSpan ts = DateTime.Now - dttt;
if (ts > new TimeSpan(0, 0, 0, 0, 20))
{
LogToScreen("!!!Thread Start Duration : " + ts.ToString());
}

Thanks for any advice.


Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

Starting threads should generally be *fairly* fast. Not the kind of
thing you want to do thousands of times in quick succession, but not
something that takes nearly a second unless you've got a *very* heavily
loaded system.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 2 '06 #5
Peter,
the method is private method of object A, which is invoked by the new
thread in 0 - 1 second after Thread.Start() - and this is my second
problem.
Could this be caused by locks on object A?

Feb 2 '06 #6
This is problem, it is a very complicated software and I'm not able to
simulate such behavior on small piece of code.

Feb 2 '06 #7
The way you are measuring a start dely is badly wrong, the resolution of the
system clock is something like 10 msec or more.

"ales" <al***********@logos.cz> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
| Hello,
|
| I have a problem with creation of new thread. The method .Start() of
| newly created thread delays current thread for 0 - 1 second.
| Cpu while delay occurs is about 5%.
|
| Any idea?
|
| Here is code used for measuring:
|
| Thread t = new Thread(...);
| DateTime dttt = DateTime.Now;
| t.Start();
| TimeSpan ts = DateTime.Now - dttt;
| if (ts > new TimeSpan(0, 0, 0, 0, 20))
| {
| LogToScreen("!!!Thread Start Duration : " + ts.ToString());
| }
|
| Thanks for any advice.
|

The way you are measuring a start delay is badly wrong, the resolution of
the system clock is something like 10 msec or more. That means it's not
possible to measure this delay the way you are doing, nor does it make
sense. The time taken by the system to start a thread can vary from a few
hundred µsecs. to a few seconds or more, all depends on the CPU speed, #of
CPU's the current system activity, current threads activity and priority
etc...
If you need fast start of a thread procedure, your only option is to use the
threadpool or a private threadpool.

Willy.


Feb 2 '06 #8
ales <al***********@logos.cz> wrote:
This is problem, it is a very complicated software and I'm not able to
simulate such behavior on small piece of code.


Then I suspect the problem isn't actually anything to do with starting
the thread.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 2 '06 #9

"ales" <al***********@logos.cz> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
| Peter,
| the method is private method of object A, which is invoked by the new
| thread in 0 - 1 second after Thread.Start() - and this is my second
| problem.
| Could this be caused by locks on object A?
|

No, a lock would not prevent a thread from "starting, it can only prevent
the start of the thread procedure.

Willy.

Feb 2 '06 #10
Jon - Yes, I think so. But reality is the thread doesn't start. There
has to be something I haven't found in last few days in which I'm
trying to figure it out.

Feb 2 '06 #11
Willy - I cannot use threadpool because I need to be able to abort
queued thread.

Feb 2 '06 #12
ales <al***********@logos.cz> wrote:
Jon - Yes, I think so. But reality is the thread doesn't start. There
has to be something I haven't found in last few days in which I'm
trying to figure it out.


Possibly, but without any more information we're not going to be able
to help you. You really need to try to work towards a short but
complete program which demonstrates the problem. Take a fresh copy of
your system and then cut things out of it until you can't cut anything
more without the problem going away.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 2 '06 #13

"ales" <al***********@logos.cz> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
| Willy - I cannot use threadpool because I need to be able to abort
| queued thread.
|

What do you mean with queued thread? Is this a running thread or is it a
work item scheduled to run on a thread?
Note that asynchronously aborting a running thread is realy bad, something
you should only consider when you are going to unload this thread's
application domain.

Willy.

Feb 2 '06 #14

"ales" <al***********@logos.cz> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...
| Jon - Yes, I think so. But reality is the thread doesn't start. There
| has to be something I haven't found in last few days in which I'm
| trying to figure it out.
|

Ok, this is getting confusing, is the thread (delayed) starting or isn't he
not starting at all?

Willy.
Feb 2 '06 #15
Yes, I meant work item scheduled to run on thread.
You are right, I'm now using thread.Abort() and should redesign the
application. Probably it is the time to do it now.
Sorry, I've written it doesn't start and meant doesn't start
immediatelly.

Feb 2 '06 #16

"ales" <al***********@logos.cz> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
| Yes, I meant work item scheduled to run on thread.
| You are right, I'm now using thread.Abort() and should redesign the
| application. Probably it is the time to do it now.
| Sorry, I've written it doesn't start and meant doesn't start
| immediatelly.
|

Ok, but I told you in another answer that you should more precisely define
"immediately", threads need time to get created but it should not take more
than a couple of milliseconds to start one on a well behaving non overloaded
system.
Notice that I said that the way you measure is flawed, you should use the
resolution timer (Stopwatch in v2 or QueryPerformanceCounter through PInvoke
in v1)to measure such delays.

Willy.
Feb 2 '06 #17
Immediately is for me 10, 20ms. Anything above 100 ms second is not
acceptable.
I do not need absolutely accurate measurement, but thank you for info,
it may be used for some future measurement.
I will try to think a bit about the design, maybe will find some
another solution, hopefuly with minimum threads and without
thread.Abort()
Thank you for your advice

Feb 2 '06 #18

"ales" <al***********@logos.cz> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
| Immediately is for me 10, 20ms. Anything above 100 ms second is not
| acceptable.
| I do not need absolutely accurate measurement, but thank you for info,
| it may be used for some future measurement.
| I will try to think a bit about the design, maybe will find some
| another solution, hopefuly with minimum threads and without
| thread.Abort()
| Thank you for your advice
|

Windows is not a real-time system, there are no strong guarantees to make
about process/thread creation times, neither about thread scheduling times.
A single thread that runs at high priority can prevent other threads to run,
the system has a mechanism to prevent starvation, but it's only after 5
seconds that the other run-able threads will get a chance to run for a
couple of quantum slices only. That's why I said on a well behaving system,
it should not take more than a few millisec's. to start a new thread, but
this is not guaranteed.

Willy.
Feb 2 '06 #19
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:

<snip>
Notice that I said that the way you measure is flawed, you should use the
resolution timer (Stopwatch in v2 or QueryPerformanceCounter through PInvoke
in v1)to measure such delays.


It's only flawed if you need to get a very exact measurement. To be
honest, I don't find QueryPerformanceCounter to be worth the effort in
1.1 - if I'm trying to time something, I almost never care about that
level of detail, as you need to get a longer period of time in order to
reduce the effect of the "noise" of the system anyway. So for a
benchmark, I try to get times of a few seconds or more, at which point
10ms either way isn't particularly significant.

(I use Stopwatch in 2.0 sometimes because it's just as easy to do that
as not to.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 3 '06 #20
> ales <al***********@logos.cz> wrote:
I have a problem with creation of new thread. The method .Start() of
newly created thread delays current thread for 0 - 1 second.
Cpu while delay occurs is about 5%.

Any idea?

Here is code used for measuring:

Thread t = new Thread(...);
DateTime dttt = DateTime.Now;
t.Start();
TimeSpan ts = DateTime.Now - dttt;
if (ts > new TimeSpan(0, 0, 0, 0, 20))
{
LogToScreen("!!!Thread Start Duration : " + ts.ToString());
}


You are not measuring the time to start a new thread.

What you are measuring is the time between calls to DateTime.Now. When you
call Start you may cause a context switch to one or more other threads - a
POSSIBLE sequence is this:

thread 1: calls Start
new thread: does stuff
thread 2: does stuff
....
thread n: does stuff
thread 1: calls DateTime.Now

The system is allowed to pick a new thread to run whenever a thread becomes
runnable and Start makes the new thread runnable.

Runnable threads at the same priority will be executed in a round robin
fashion so if all the threads are runnable the system can put thread 1 to
the end of the queue behind all the others when it executes Start.

Even DateTime.Now COULD be a scheduling point depending on exactly how the
time is obtained.

Feb 3 '06 #21

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
| Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
|
| <snip>
|
| > Notice that I said that the way you measure is flawed, you should use
the
| > resolution timer (Stopwatch in v2 or QueryPerformanceCounter through
PInvoke
| > in v1)to measure such delays.
|
| It's only flawed if you need to get a very exact measurement. To be
| honest, I don't find QueryPerformanceCounter to be worth the effort in
| 1.1 - if I'm trying to time something, I almost never care about that
| level of detail, as you need to get a longer period of time in order to
| reduce the effect of the "noise" of the system anyway. So for a
| benchmark, I try to get times of a few seconds or more, at which point
| 10ms either way isn't particularly significant.
|
| (I use Stopwatch in 2.0 sometimes because it's just as easy to do that
| as not to.)

Agreed, but this is not a benchmark. here the OP 'thinks' he needs to
measure the time it takes to start a thread in a real application, well, the
way he does is flawed so the result has little or no value. Note that
benchmarking thread starts by spawning threads for a longer period have
little value either, the results obtained are mostly "best case" and they
should not be used to answer the question "do I spawn new threads in
succession or do I use a pool of threads". There are other, more important
costs than 'start times' to consider when using threads.

Willy.

Feb 3 '06 #22
Willy Denoyette [MVP] wrote:
| It's only flawed if you need to get a very exact measurement. To be
| honest, I don't find QueryPerformanceCounter to be worth the effort in
| 1.1 - if I'm trying to time something, I almost never care about that
| level of detail, as you need to get a longer period of time in order to
| reduce the effect of the "noise" of the system anyway. So for a
| benchmark, I try to get times of a few seconds or more, at which point
| 10ms either way isn't particularly significant.
|
| (I use Stopwatch in 2.0 sometimes because it's just as easy to do that
| as not to.)

Agreed, but this is not a benchmark. here the OP 'thinks' he needs to
measure the time it takes to start a thread in a real application, well, the
way he does is flawed so the result has little or no value.
I disagree. I suspect it's only a problem for him if it takes a fair
amount of time, eg 10ms. In fact, I suspect that it must be taking
longer than that for it to have been noticed in the first place.
Note that benchmarking thread starts by spawning threads for a longer period have
little value either, the results obtained are mostly "best case" and they
should not be used to answer the question "do I spawn new threads in
succession or do I use a pool of threads". There are other, more important
costs than 'start times' to consider when using threads.


I certainly agree with that, but I don't think it invalidates the
coarse test of "is this where my problem is" by using DateTime.Now. For
1.1 projects, that's considerably simpler than using performance
counters, and is often all that's needed.

Jon

Feb 3 '06 #23

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
| Willy Denoyette [MVP] wrote:
| > | It's only flawed if you need to get a very exact measurement. To be
| > | honest, I don't find QueryPerformanceCounter to be worth the effort in
| > | 1.1 - if I'm trying to time something, I almost never care about that
| > | level of detail, as you need to get a longer period of time in order
to
| > | reduce the effect of the "noise" of the system anyway. So for a
| > | benchmark, I try to get times of a few seconds or more, at which point
| > | 10ms either way isn't particularly significant.
| > |
| > | (I use Stopwatch in 2.0 sometimes because it's just as easy to do that
| > | as not to.)
| >
| > Agreed, but this is not a benchmark. here the OP 'thinks' he needs to
| > measure the time it takes to start a thread in a real application, well,
the
| > way he does is flawed so the result has little or no value.
|
| I disagree. I suspect it's only a problem for him if it takes a fair
| amount of time, eg 10ms. In fact, I suspect that it must be taking
| longer than that for it to have been noticed in the first place.
|

Well, it looks like only the OP can answer that question, maybe he did
notice something but IMO it has nothing to do with a thread "start delay",
read one of it's other replies that asks about a lock on his thread
procedure, IMO he noticed a (variable?) delay when executing the thread
proc, but thinks it's due to the thread start delay.

Anyway there are far better ways to measure such intervals (if you ever need
to), using a timer with a 10-20 msec. resolution to measure possible
millisecond or even sub-milliseconds intervals makes no sense, unless you
know that a result of 0 could also mean 15 msecs. and 16 msec. could also be
30 msec.
| > Note that benchmarking thread starts by spawning threads for a longer
period have
| > little value either, the results obtained are mostly "best case" and
they
| > should not be used to answer the question "do I spawn new threads in
| > succession or do I use a pool of threads". There are other, more
important
| > costs than 'start times' to consider when using threads.
|
| I certainly agree with that, but I don't think it invalidates the
| coarse test of "is this where my problem is" by using DateTime.Now. For
| 1.1 projects, that's considerably simpler than using performance
| counters, and is often all that's needed.
|

Who said performance counters? I'm talking about a Win32 API call
QueryPerformanceCounter(...), all you need is a two PInvoke declarations
wrapped in a utility class and you are done, just like Stopwatch does,
right?.
Even if you don't wan't to do all this you can :

start a utility like (but not restricted to) dbgvw.exe (from
www.sysinternals.com)
change your code like this:
Debug.WriteLine("start")
t.Start();
Debug.WriteLine("started")
and oeps instant accurate (in terms of whats possible on NT like systems).

Willy.


Feb 3 '06 #24
Willy Denoyette [MVP] wrote:
| I disagree. I suspect it's only a problem for him if it takes a fair
| amount of time, eg 10ms. In fact, I suspect that it must be taking
| longer than that for it to have been noticed in the first place.

Well, it looks like only the OP can answer that question, maybe he did
notice something but IMO it has nothing to do with a thread "start delay",
read one of it's other replies that asks about a lock on his thread
procedure, IMO he noticed a (variable?) delay when executing the thread
proc, but thinks it's due to the thread start delay.
Ironically, the OP has answered the question of what accuracy he wants:
"Immediately is for me 10, 20ms. Anything above 100 ms second is not
acceptable."

In other words, using DateTime.Now is more than adequate to tell the
difference between acceptable and unacceptable.
Anyway there are far better ways to measure such intervals (if you ever need
to), using a timer with a 10-20 msec. resolution to measure possible
millisecond or even sub-milliseconds intervals makes no sense, unless you
know that a result of 0 could also mean 15 msecs. and 16 msec. could also be
30 msec.
And if you need to measure those intervals, I agree. I just don't think
that such a level of accuracy is called for in this case.
| I certainly agree with that, but I don't think it invalidates the
| coarse test of "is this where my problem is" by using DateTime.Now. For
| 1.1 projects, that's considerably simpler than using performance
| counters, and is often all that's needed.

Who said performance counters? I'm talking about a Win32 API call
QueryPerformanceCounter(...),
I couldn't remember the exact name of the API call, but knew it was
*something* like the above. It's not entirely unreasonable to think
that a call to "QueryPerformanceCounter" has something to do with
performance counters :)
all you need is a two PInvoke declarations
wrapped in a utility class and you are done, just like Stopwatch does,
right?.
So do you have that utility class handy in every piece of code you
write? Or do you need to always add a reference to a project that
contains it? I'd rather not do that unless I really need to - and I see
no evidence for that need in this case.
Even if you don't wan't to do all this you can :

start a utility like (but not restricted to) dbgvw.exe (from
www.sysinternals.com)
change your code like this:
Debug.WriteLine("start")
t.Start();
Debug.WriteLine("started")
and oeps instant accurate (in terms of whats possible on NT like systems).


Again though, it's more hassle than using DateTime.Now if accuracy like
that isn't required.

Jon

Feb 3 '06 #25

"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:xe********************@fe3.news.blueyonder.co .uk...
|> ales <al***********@logos.cz> wrote:
| >> I have a problem with creation of new thread. The method .Start() of
| >> newly created thread delays current thread for 0 - 1 second.
| >> Cpu while delay occurs is about 5%.
| >>
| >> Any idea?
| >>
| >> Here is code used for measuring:
| >>
| >> Thread t = new Thread(...);
| >> DateTime dttt = DateTime.Now;
| >> t.Start();
| >> TimeSpan ts = DateTime.Now - dttt;
| >> if (ts > new TimeSpan(0, 0, 0, 0, 20))
| >> {
| >> LogToScreen("!!!Thread Start Duration : " + ts.ToString());
| >> }
|
| You are not measuring the time to start a new thread.
|
| What you are measuring is the time between calls to DateTime.Now. When you
| call Start you may cause a context switch to one or more other threads - a
| POSSIBLE sequence is this:
|
| thread 1: calls Start
| new thread: does stuff
| thread 2: does stuff
| ...
| thread n: does stuff
| thread 1: calls DateTime.Now
|
| The system is allowed to pick a new thread to run whenever a thread
becomes
| runnable and Start makes the new thread runnable.
|
| Runnable threads at the same priority will be executed in a round robin
| fashion so if all the threads are runnable the system can put thread 1 to
| the end of the queue behind all the others when it executes Start.
|
| Even DateTime.Now COULD be a scheduling point depending on exactly how the
| time is obtained.
|
|

Exactly, what the OP is measuring is not the time it takes to start a
thread, it's the time his thread is off CPU. Or the interval between two
thread switches, one to start the OS thread and another switch when his
thread gets scheduled again. What happens in between is just a matter of
system activity, if you happen to have a single long running high priority
thread in the system it can take seconds to get the CPU back for your
thread.

Willy.
Feb 3 '06 #26
I think Jon has given you the best advice. I would start with the simplest
example of your threaded application that you can, and add functionality
until it breaks.

The key to troubleshooting a complex problem that you can't debug is to just
divide and conquer. Use Visual Source Safe so you can roll back, then add
functionality in medium sized blocks. When you break the application, roll
back to the last working version, and then start adding code in smaller
blocks. You're basically doing a successive approximation of your code to
break it down.
--
Dale Preston
MCAD C#
MCSE, MCDBA
"ales" wrote:
Jon - Yes, I think so. But reality is the thread doesn't start. There
has to be something I haven't found in last few days in which I'm
trying to figure it out.

Feb 3 '06 #27

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
| Willy Denoyette [MVP] wrote:
| > | I disagree. I suspect it's only a problem for him if it takes a fair
| > | amount of time, eg 10ms. In fact, I suspect that it must be taking
| > | longer than that for it to have been noticed in the first place.
| >
| > Well, it looks like only the OP can answer that question, maybe he did
| > notice something but IMO it has nothing to do with a thread "start
delay",
| > read one of it's other replies that asks about a lock on his thread
| > procedure, IMO he noticed a (variable?) delay when executing the thread
| > proc, but thinks it's due to the thread start delay.
|
| Ironically, the OP has answered the question of what accuracy he wants:
| "Immediately is for me 10, 20ms. Anything above 100 ms second is not
| acceptable."
|

Yes, but that was AFTER I told him his way of measuring was flawed, he never
said what exactly he measured not what he was expecting before that. If you
measure something that normally takes a from ~500 µseconds up to a few 10
milliseconds you shouldn't use a timer with a resolution of 10 - 20 msecs.
| In other words, using DateTime.Now is more than adequate to tell the
| difference between acceptable and unacceptable.
|
| > Anyway there are far better ways to measure such intervals (if you ever
need
| > to), using a timer with a 10-20 msec. resolution to measure possible
| > millisecond or even sub-milliseconds intervals makes no sense, unless
you
| > know that a result of 0 could also mean 15 msecs. and 16 msec. could
also be
| > 30 msec.
|
| And if you need to measure those intervals, I agree. I just don't think
| that such a level of accuracy is called for in this case.
|

Again, he only mentioned his requirements after I asked for, besides, what's
wrong with a higher level of accuracy, does it hurt?.

| > | I certainly agree with that, but I don't think it invalidates the
| > | coarse test of "is this where my problem is" by using DateTime.Now.
For
| > | 1.1 projects, that's considerably simpler than using performance
| > | counters, and is often all that's needed.
| >
| > Who said performance counters? I'm talking about a Win32 API call
| > QueryPerformanceCounter(...),
|
| I couldn't remember the exact name of the API call, but knew it was
| *something* like the above. It's not entirely unreasonable to think
| that a call to "QueryPerformanceCounter" has something to do with
| performance counters :)
|

Actually, it's a call into Kernel32.dll a system library, it's the same API
is used by the performance counters and now Stopwatch but not the other way
around.
| > all you need is a two PInvoke declarations
| > wrapped in a utility class and you are done, just like Stopwatch does,
| > right?.
|
| So do you have that utility class handy in every piece of code you
| write? Or do you need to always add a reference to a project that
| contains it? I'd rather not do that unless I really need to - and I see
| no evidence for that need in this case.
|

I don't. I have more accurate tools available if really needed, tools that
count the # of CPU instructions executed between two trigger points for
instance, I rarely feel the need to measure such delays though when running
managed code.
However, other people may find such a library of tools usefull, IMO it's one
of the reasons MS has added Stopwatch to the framework, just to prevent
people to re-invent the wheel.
| > Even if you don't wan't to do all this you can :
| >
| > start a utility like (but not restricted to) dbgvw.exe (from
| > www.sysinternals.com)
| > change your code like this:
| > Debug.WriteLine("start")
| > t.Start();
| > Debug.WriteLine("started")
| > and oeps instant accurate (in terms of whats possible on NT like
systems).
|
| Again though, it's more hassle than using DateTime.Now if accuracy like
| that isn't required.
|

Oh come on, where's the hassle ? Start the debug viewer?
What's the difference between calling

DateTime start = DateTime.Now;
...
Console.WriteLine("{0}", TimeSpan(.....));

vs.
Debug.Write("...")
....
Debug.Write("...")

Agreed, when precision is not an issue, you can do with DateTime.Now, but if
you really need to measure things that will take less than a few hundred
milliseconds there are better ways like Stopwatch in v2 and
QueryPerformanceXXXX in v1.

Willy.

Feb 3 '06 #28
Willy Denoyette [MVP] wrote:
| Ironically, the OP has answered the question of what accuracy he wants:
| "Immediately is for me 10, 20ms. Anything above 100 ms second is not
| acceptable."

Yes, but that was AFTER I told him his way of measuring was flawed, he never
said what exactly he measured not what he was expecting before that. If you
measure something that normally takes a from ~500 µseconds up to a few 10
milliseconds you shouldn't use a timer with a resolution of 10 - 20 msecs.
Certainly. I wasn't arguing that you should have been prescient - you
just seemed to still regard it as the wrong way of doing things despite
the answer given. Apologies if I've read too much into what you've
written.
| And if you need to measure those intervals, I agree. I just don't think
| that such a level of accuracy is called for in this case.

Again, he only mentioned his requirements after I asked for, besides, what's
wrong with a higher level of accuracy, does it hurt?.
Yes, if it takes longer to do, adding PInvoke calls or downloading an
extra tool. Using Stopwatch is a different kettle of fish, of course.

<snip performance counter discussion - not terribly relevant>
| So do you have that utility class handy in every piece of code you
| write? Or do you need to always add a reference to a project that
| contains it? I'd rather not do that unless I really need to - and I see
| no evidence for that need in this case.

I don't. I have more accurate tools available if really needed, tools that
count the # of CPU instructions executed between two trigger points for
instance, I rarely feel the need to measure such delays though when running
managed code.
However, other people may find such a library of tools usefull, IMO it's one
of the reasons MS has added Stopwatch to the framework, just to prevent
people to re-invent the wheel.
Absolutely - and it's great that they have. However, when working with
1.1, if I don't really need a wheel, I don't think it's worth
reinventing it :)

<sysinternals tool>
| Again though, it's more hassle than using DateTime.Now if accuracy like
| that isn't required.

Oh come on, where's the hassle ? Start the debug viewer?
Yes - discover the existence of it, download it (and tell all your
colleagues about it), then start it when you need it. It may not be
*very* much hassle, but it's more hassle than not doing it in the first
place.
Agreed, when precision is not an issue, you can do with DateTime.Now, butif
you really need to measure things that will take less than a few hundred
milliseconds there are better ways like Stopwatch in v2 and
QueryPerformanceXXXX in v1.


We certainly agree that if you need *accurate* timing it's worth using
those, and in 2.0 I'd suggest using Stopwatch anyway. Under 1.1 though,
I'd only go for the other techniques when I really needed the
precision. It's not just that you *can* do it, but that it's *simpler*
to do it unless you already happen to have everything available.

Jon

Feb 3 '06 #29
See inline

**** Willy
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
Willy Denoyette [MVP] wrote:
| Ironically, the OP has answered the question of what accuracy he wants:
| "Immediately is for me 10, 20ms. Anything above 100 ms second is not
| acceptable."

Yes, but that was AFTER I told him his way of measuring was flawed, he
never
said what exactly he measured not what he was expecting before that. If
you
measure something that normally takes a from ~500 µseconds up to a few 10
milliseconds you shouldn't use a timer with a resolution of 10 - 20 msecs.
Certainly. I wasn't arguing that you should have been prescient - you
just seemed to still regard it as the wrong way of doing things despite
the answer given. Apologies if I've read too much into what you've
written.
| And if you need to measure those intervals, I agree. I just don't think
| that such a level of accuracy is called for in this case.

Again, he only mentioned his requirements after I asked for, besides,
what's
wrong with a higher level of accuracy, does it hurt?.
Yes, if it takes longer to do, adding PInvoke calls or downloading an
extra tool. Using Stopwatch is a different kettle of fish, of course.

**** Willy
The extra tools have to be downloaded once and is something which is good to
have in your developers toolset anyway, just like a bunch of other
diagnostic tools from the same authors or others (see later).

As far as the API call goes, it's not more than a couple of source code
lines, wrap it in a class and drop it in a library, you can start using it
when appropriate and you can remove it when it's covered by the framework,
don't you have a small private library with some utility classes in your
toolset? I'm almost sure you do!
Really, there is a lot more missing in the framework that has to be done by
calling API's, the V1 framework doesn't cover half of what I need (the
windows security stuff is completely missing), jeez, you can't impersonate a
user without a call to LogonUser() even not in V2. You know why?
*****

<snip performance counter discussion - not terribly relevant>
| So do you have that utility class handy in every piece of code you
| write? Or do you need to always add a reference to a project that
| contains it? I'd rather not do that unless I really need to - and I see
| no evidence for that need in this case.

I don't. I have more accurate tools available if really needed, tools that
count the # of CPU instructions executed between two trigger points for
instance, I rarely feel the need to measure such delays though when
running
managed code.
However, other people may find such a library of tools usefull, IMO it's
one
of the reasons MS has added Stopwatch to the framework, just to prevent
people to re-invent the wheel.
Absolutely - and it's great that they have. However, when working with
1.1, if I don't really need a wheel, I don't think it's worth
reinventing it :)

*** Willy
You don't have to re-invent, if you don't wan't to use the Debug.Trace or
Debug.Write call, the output goes to a debug viewer or to the systems
supplied trace viewer (tracelog.exe), it's just a matter of knowing your
tools really.
***
<sysinternals tool>
| Again though, it's more hassle than using DateTime.Now if accuracy like
| that isn't required.

Oh come on, where's the hassle ? Start the debug viewer?
Yes - discover the existence of it, download it (and tell all your
colleagues about it), then start it when you need it. It may not be
*very* much hassle, but it's more hassle than not doing it in the first
place.

*** Willy
If you need to measure, be sure how and what to measure and use the right
tools, if you think DateTime.Now is the right thing for you, ok go for it,
I'm sure you know about the timer precison - and if it returns 20 msecs.
that it could be somethins between 1 and 20 msec, but are you sure all
others know this too? Sorry, but I'm not.
***
Agreed, when precision is not an issue, you can do with DateTime.Now, but
if
you really need to measure things that will take less than a few hundred
milliseconds there are better ways like Stopwatch in v2 and
QueryPerformanceXXXX in v1.


We certainly agree that if you need *accurate* timing it's worth using
those, and in 2.0 I'd suggest using Stopwatch anyway. Under 1.1 though,
I'd only go for the other techniques when I really needed the
precision. It's not just that you *can* do it, but that it's *simpler*
to do it unless you already happen to have everything available.

*** Willy
Again, you have the tools available, a serious developer has an MSDN
subscription (as you do) containing the SDK's and the system comes with a
bunch of tools. I know most aren't well known, they don't have a fancy UI,
but hey! they are developer tools, you only need to learn to use them, you
will be suprised of their power and 'ease' of use. No more silly discussion
like:

"I a have a memory leak",
how do you know?
"taskman told me so".
No, use vadump.exe or the kernel debugger, but please stop guessing where
your memory goes and who's to blame. If these tools are too complex, ok,
they require some expertise, but they are what you need to accurately trace
memmory and other leaks, no more guesswork. After some time you won't use
them that frequently, you can make some educated "guess" because you know
what really goes on.

The same goes for VS, some are quite happy with it's toolset it's debugger
and stuff, it has everything most people need and a pretty facade (well sort
of), but it's largely over-engineerd it's too heavy weight, (it looks like
Word) at least for me.

well I'm not and therefore I'm using other tools, not well integrated fancy
UI, most command line oriented, but much more efficient.
***

Willy.

Feb 3 '06 #30
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
See inline


<snip>

I think we'll have to agree to differ. I don't have a single library
which is *always* around whatever project I'm working on (I couldn't
very easily, as I work on code for pleasure and commercially, and not
even all the commercial stuff has common references), and for the most
part I *am* content with the facilities provided by the VS debugger.
Not always - in particular it's sometimes handy to get cordbg out to
see what's getting inlined etc - but I try to avoid the debugger anyway
for the most part.

I'll keep using DateTime.Now when I don't need anything more accurate -
which I haven't done for a very long time.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 3 '06 #31
Willy:
Windows is not a real-time system, there are no strong guarantees to make
about process/thread creation times, neither about thread scheduling times.
A single thread that runs at high priority can prevent other threads to run,
the system has a mechanism to prevent starvation, but it's only after 5
seconds that the other run-able threads will get a chance to run for a
couple of quantum slices only. That's why I said on a well behaving system,
it should not take more than a few millisec's. to start a new thread, but
this is not guaranteed.


Ok, but the situation is the cpu is max 10% and there is nothing
hapenning for one second. Can you explain this? Why the new thread
doesn't start and existing thread is suspended?

Feb 8 '06 #32
Dale - again, the application is too complex. I would spend a lot of
time by preparing it. And time is what prevents doing it.

Feb 8 '06 #33
Why is there an existing thread? Could you not reuse that thread instead of
starting another one?
Also, add some debug messages with ms timespans in your start logic to try
to catch where your getting slow. It could be your waiting on a lock or
something in your thread. How many threads are you starting? Why not just
start a few worker threads that loop for work instead of creating new
threads?

--
William Stacey [MVP]

"ales" <al***********@logos.cz> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
| Willy:
| >Windows is not a real-time system, there are no strong guarantees to make
| >about process/thread creation times, neither about thread scheduling
times.
| >A single thread that runs at high priority can prevent other threads to
run,
| >the system has a mechanism to prevent starvation, but it's only after 5
| >seconds that the other run-able threads will get a chance to run for a
| >couple of quantum slices only. That's why I said on a well behaving
system,
| >it should not take more than a few millisec's. to start a new thread, but
| >this is not guaranteed.
|
| Ok, but the situation is the cpu is max 10% and there is nothing
| hapenning for one second. Can you explain this? Why the new thread
| doesn't start and existing thread is suspended?
|
Feb 8 '06 #34

"ales" <al***********@logos.cz> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
| Willy:
| >Windows is not a real-time system, there are no strong guarantees to make
| >about process/thread creation times, neither about thread scheduling
times.
| >A single thread that runs at high priority can prevent other threads to
run,
| >the system has a mechanism to prevent starvation, but it's only after 5
| >seconds that the other run-able threads will get a chance to run for a
| >couple of quantum slices only. That's why I said on a well behaving
system,
| >it should not take more than a few millisec's. to start a new thread, but
| >this is not guaranteed.
|
| Ok, but the situation is the cpu is max 10% and there is nothing
| hapenning for one second. Can you explain this? Why the new thread
| doesn't start and existing thread is suspended?
|

No, I can't. But what you should do is measure the interval between the
Thread.Start call and the moment you enter the thread procedure (well your
private method...), because this is the real start time.

DateTime dttt = DateTime.Now;
t.Start();
ThreadProcWhatever(...)
{
TimeSpan ts = DateTime.Now - dttt;
...

}

Willy.
Feb 8 '06 #35

William Stacey [MVP] wrote:
Why is there an existing thread? Could you not reuse that thread instead of
starting another one?
By existing thred is meant actual thread which starts new thread
Also, add some debug messages with ms timespans in your start logic to try
to catch where your getting slow. It could be your waiting on a lock or
something in your thread.
Yes, I added a lot of debug messages, but still nothing :(
How many threads are you starting?
At this point just one.
Why not just start a few worker threads that loop for work instead of creating new threads?


Yes, I will do it this way.

Feb 9 '06 #36
Willy Denoyette [MVP] wrote:
No, I can't. But what you should do is measure the interval between the
Thread.Start call and the moment you enter the thread procedure (well your
private method...), because this is the real start time.

DateTime dttt = DateTime.Now;
t.Start();
ThreadProcWhatever(...)
{
TimeSpan ts = DateTime.Now - dttt;
...


Yes, this is second issue. This start time is from few millisedonds to
one second too. And it is the same for thread run either by new
Thread() or ThreadPool.QueueWorkItem().

Feb 9 '06 #37

"ales" <al***********@logos.cz> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
| Willy Denoyette [MVP] wrote:
|
| > No, I can't. But what you should do is measure the interval between the
| > Thread.Start call and the moment you enter the thread procedure (well
your
| > private method...), because this is the real start time.
| >
| > DateTime dttt = DateTime.Now;
| > t.Start();
| >
| >
| > ThreadProcWhatever(...)
| > {
| > TimeSpan ts = DateTime.Now - dttt;
| > ...
|
| Yes, this is second issue. This start time is from few millisedonds to
| one second too. And it is the same for thread run either by new
| Thread() or ThreadPool.QueueWorkItem().
|

Well that means your CPU is busy with other threads, could be higher
priority or equal priority threads. Could be that there is a lot of IO
activity, while this doesn't generate a lot of CPU activity, it may well
wake up a thread or a number of threads very frequently and as these threads
have their priority boosted (after an IO) it might be the reason for the
delay's.

Willy.
Feb 9 '06 #38

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Olivier Parisy | last post: by
6 posts views Thread by vee_kay | last post: by
28 posts views Thread by dcrespo | last post: by
20 posts views Thread by Doug Thews | last post: by
7 posts views Thread by Doug Thews | last post: by
reply views Thread by Dave Coate | last post: by
11 posts views Thread by Jon Slaughter | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.