Most efficient way of getting current hour

[Ram Prasad]

Hello,

I am pretty much inexperienced in C, I have used perl etc but
obvioulsy when It comes to efficiency I have to turn to C

Currenlty trying to write a patch in to my current uucp systems to
implement ratelimits.
For this I need to get-current-hour. Probably thousands of times in
an hour.

What will be the best way of doing so. If have written this code .. is
it ok enough ?

----------
#include <time.h>
#include <stdio.h>
int main (void)
{
struct tm *ts;
time_t mytime = time(0);
ts = localtime(&mytime);
printf("Current Hour is %d\n",ts->tm_hour); /* print is just for
the sample code .. */
return 0;
}

-----------

 

[Eric Sosman]

Hello,

I am pretty much inexperienced in C, I have used perl etc but
obvioulsy when It comes to efficiency I have to turn to C

It's not "obvious," but that's another topic.

Currenlty trying to write a patch in to my current uucp systems to
implement ratelimits.
For this I need to get-current-hour. Probably thousands of times in
an hour.

What will be the best way of doing so. If have written this code .. is
it ok enough ?

----------
#include<time.h>
#include<stdio.h>
int main (void)
{
struct tm *ts;
time_t mytime = time(0);
ts = localtime(&mytime);
printf("Current Hour is %d\n",ts->tm_hour); /* print is just for
the sample code .. */
return 0;
}

This looks all right. Whether it's "ok enough" is for you to
decide: Put it in your program and *measure* the performance. If
the performance is good enough, stop. Look for fancier approaches
only if the performance is poor *and* you've determined that the
performance of this portion is a contributor.

 

[Richard Bos]

For this I need to get-current-hour. Probably thousands of times in
an hour.

What will be the best way of doing so. If have written this code .. is
it ok enough ?

struct tm *ts;
time_t mytime = time(0);
ts = localtime(&mytime);
printf("Current Hour is %d\n",ts->tm_hour);

Thousands of times in an hour... do the arithmetic. That is what, once
or twice a second? For that, what you have should be more than amply
sufficient. It also has the advantage of being pure ISO C, so it should
work anywhere.

Richard

 

[Moi]

Hello,

I am pretty much inexperienced in C, I have used perl etc but obvioulsy
when It comes to efficiency I have to turn to C

Currenlty trying to write a patch in to my current uucp systems to
implement ratelimits.
For this I need to get-current-hour. Probably thousands of times in an
hour.

What will be the best way of doing so. If have written this code .. is
it ok enough ?

As the others have said, it looks pretty good.
There might be a small problem:
Local time takes into consideration your local timezone
*and DST-settings*. DST will cause leap-hours.

So your rate-limiting code should be aware that the hour 02:00-03:00
repeats once a year and is absent once a year.
Maybe gmtime() would be simpler in this respect.

HTH,
AvK

 

[jacob navia]

Ram Prasad a écrit :

Hello,

I am pretty much inexperienced in C, I have used perl etc but
obvioulsy when It comes to efficiency I have to turn to C

Currenlty trying to write a patch in to my current uucp systems to
implement ratelimits.
For this I need to get-current-hour. Probably thousands of times in
an hour.

What will be the best way of doing so. If have written this code .. is
it ok enough ?

----------
#include <time.h>
#include <stdio.h>
int main (void)
{
struct tm *ts;
time_t mytime = time(0);
ts = localtime(&mytime);
printf("Current Hour is %d\n",ts->tm_hour); /* print is just for
the sample code .. */
return 0;
}

Much more efficient than to look at micro optimizations is to ask yourself:

Do I need to get the hour almost each second?

Couldn't I setup a thread that asks for the hour, then sleeps for 3550
seconds and then asks for the hour again?

Optimize the algorithm and forget about the micro optimizations...

 

[Ben Pfaff]

Much more efficient than to look at micro optimizations is to ask yourself:

Do I need to get the hour almost each second?

Couldn't I setup a thread that asks for the hour, then sleeps for 3550
seconds and then asks for the hour again?

That seems like a good way to have the wrong hour for up to 3549
seconds.

 

[Keith Thompson]

That seems like a good way to have the wrong hour for up to 3549
seconds.

So get the current time, store the hour, and sleep until the top of the
next hour.

There's some danger that the thread won't wake up in time, and if you're
not already using threads you probably don't want to start just for this
purpose.

Assuming a call to time() is cheap, you could do something like this:

Get the current time.

Compute and store the current hour and the time_t representation
for the top of the next hour. (This might be slightly expensive,
but it's only done once an hour.)

On each successive call, get the current time again; if it's
less than the stored value, just return the stored hour.

For 100% portability, you need to use difftime() to compare
the current time to the stored time. With only a slight loss
of portability, you can assume that time_t values increase
monotonically.

And of course you need to think about DST transitions.

 

[D. Stussy]

So get the current time, store the hour, and sleep until the top of the
next hour.

There's some danger that the thread won't wake up in time, and if you're
not already using threads you probably don't want to start just for this
purpose.

Assuming a call to time() is cheap, you could do something like this:

Get the current time.

Compute and store the current hour and the time_t representation
for the top of the next hour. (This might be slightly expensive,
but it's only done once an hour.)

On each successive call, get the current time again; if it's
less than the stored value, just return the stored hour.

For 100% portability, you need to use difftime() to compare
the current time to the stored time. With only a slight loss
of portability, you can assume that time_t values increase
monotonically.

And of course you need to think about DST transitions.

Since your original question was about efficiency, you may wish to consider
another approach:

Fetch the time (in seconds) as an integer. hour = ( time / 3600) % 24.
Of course, that should result in a UTC hour, but your question didn't
specify that the hour be returned in terms of the local time zone.

The above approach may yield the same result in less cpu-runtime as there's
less library subroutine action, and the computations are relatively quick.

 

[jacob navia]

Ben Pfaff a écrit :

That seems like a good way to have the wrong hour for up to 3549
seconds.

Yes, I intended to say that sleeps for n seconds until the next hour
arrives:
(1) get the current time
(2) set a global with the hour
(3) sleep until just before the next hour arrives
(4) wake up, read the hour again, and sleep until the next hour arrives

 

[Ram Prasad]

Ram Prasad a écrit :









Much more efficient than to look at micro optimizations is to ask yourself:

Do I need to get the hour almost each second?

Couldn't I setup a thread that asks for the hour, then sleeps for 3550
seconds and then asks for the hour again?

Optimize the algorithm and forget about the micro optimizations...

Would have loved to do that but ..
As I said , the gethour() will be used in a uucp server. Each server
child-process (uucico) will have a different pid. How can I share a
thread info ?. Since this is a pretty busy server there are usually
20-50 concurrent server processes running and new ones will get
spawned on newer connections

Is there a way I can re-use the gethour() call output.

OTOH .. I know that this function will be least heavy part in uucico.
But what I want to ensure is that my patch itself does not do anything
daft to contribute to the load.

 

[Seebs]

Would have loved to do that but ..
As I said , the gethour() will be used in a uucp server. Each server
child-process (uucico) will have a different pid. How can I share a
thread info ?. Since this is a pretty busy server there are usually
20-50 concurrent server processes running and new ones will get
spawned on newer connections

Is there a way I can re-use the gethour() call output.

OTOH .. I know that this function will be least heavy part in uucico.
But what I want to ensure is that my patch itself does not do anything
daft to contribute to the load.

Trying to share this information between processes will, at a bare minimum,
use more time than it would take to run the calculation several times per
process per second.

Seriously, this is not worth optimizing. Call time(NULL) and run with it.
You're doing an I/O bound operation; compared to that, the time taken to
find the current time is immeasurably small.

-s

 

[Richard Bos]

As I said , the gethour() will be used in a uucp server. Each server
child-process (uucico) will have a different pid. How can I share a
thread info ?. Since this is a pretty busy server there are usually
20-50 concurrent server processes running and new ones will get
spawned on newer connections

Again, do the arithmetic. With those numbers, the gain you get from
obfuscating or system-specialising your code is _never_ going to be
worth the trouble.
Go with the perfectly good, perfectly portable code you posted first. It
will suffice.

Richard