speed of reading the real time clock?

Thread view:

bugbear - 16 May 2006 11:33 GMT

Does anyone know (off hand) how long
new java.util.Date() takes?

I'd like to time (i.e. take
start time from end time) a method
and report (log4j) slow ones.

But I'm concerned at the overhead of
the 2 calls to Date().

I have a dim memory that accessing the RTC
can be slow on some machines.

Does anybody have any good timing
information?

BugBear

Reply to this Message

Tobias Schröer - 16 May 2006 12:20 GMT

Hi,

bugbear schrieb:

> Does anyone know (off hand) how long
> new java.util.Date() takes?
[quoted text clipped - 13 lines]
>
> BugBear

I'd rather use System.currentTimeMillis() instead of new Date(). Ok,
it's pretty much the same (new Date() does nothing else than store the
System.currentTimeMillis() value), but you spare a new Object.

If you use JDK 1.5 or above, you can alternativly use System.nanoTime(),
but be sure to read the API doc.

About costs for RTC access I don't now :(

Tobi

Reply to this Message

Robert Klemme - 16 May 2006 12:32 GMT

> Does anyone know (off hand) how long
> new java.util.Date() takes?
>
> I'd like to time (i.e. take
> start time from end time) a method
> and report (log4j) slow ones.

As Tobias pointed out you should use System.currentTimeMillis() as the
overhead of creating an object is significant.

But your problem has been solved already: what you really want is a
profiler. That will also take into consideration how often a method was
called. You can use "java -Xrunhprof" or other tools. There's plenty
out there for Java.

Kind regards

robert

Reply to this Message

bugbear - 16 May 2006 12:59 GMT

>> Does anyone know (off hand) how long
>> new java.util.Date() takes?
[quoted text clipped - 10 lines]
> called. You can use "java -Xrunhprof" or other tools. There's plenty
> out there for Java.

I'm afraid not; I want to leave the information gathering
stuff enabled for *weeks*, on live customer site;

The performance of the method will vary greatly with
parameters, so I want to "flag up" issues, and either
change the code, or train the operators to work
in other ways.

When I detect a slow call to the method I need
to log a good deal of context, far more than a profiler
does.

BugBear

Reply to this Message

Alex Hunsley - 16 May 2006 13:04 GMT

> Does anyone know (off hand) how long
> new java.util.Date() takes?

I suppose it depends on the speed of your computer and JVM
implementation. Why don't you write some code to repeatedly create new
Date objects, thousands of times, then divide by whatever to get the
average time?

> I'd like to time (i.e. take
> start time from end time) a method
> and report (log4j) slow ones.
>
> But I'm concerned at the overhead of
> the 2 calls to Date().

If the two calls take approximately the same time (say, they both took
exactly 5 minutes), then you don't need to worry about the time taken to
call Date, since both timings are delayed approximately the same amount
by the call to Date (I would think).

Reply to this Message

Thomas Weidenfeller - 16 May 2006 13:17 GMT

> If the two calls take approximately the same time (say, they both took
> exactly 5 minutes), then you don't need to worry about the time taken to
> call Date, since both timings are delayed approximately the same amount
> by the call to Date (I would think).

That assumption is is unlikely to be correct. If we assume that the
model for a single Date call is (largely simplified):

[pre-overhead | current time taken | post-overhead]

With pre-overhead containing things like allocating the object, and
post-overhead containing things like storing the acquired time value and
returning an object reference, a simple model of the whole procedure
would be:

[pre-overhead | current time taken | post-overhead]
[thing to measure]
[pre-overhead | current time taken | post-overhead]

So you end up with a start time which is post-overhead to early, and an
end-time which is pre-overhead to late. Even if both overheads are
exactly the same, they won't even-out each other. Your total error would
be post-overhead + pre-overhead.

In real life you have much more fun. What e.g. if the JIT decides to
compile Date during the first invocation?

/Thomas

Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

Reply to this Message

Thomas Fritsch - 16 May 2006 14:10 GMT

> In real life you have much more fun. What e.g. if the JIT decides to
> compile Date during the first invocation?

Or what if the GC decides to jump in (may be because 100000 finalizable
Date objects have been accumulated) ?

Signature

Thomas

Reply to this Message

P.Hill - 21 May 2006 20:53 GMT

>> In real life you have much more fun. What e.g. if the JIT decides to
>> compile Date during the first invocation?
>
> Or what if the GC decides to jump in (may be because 100000 finalizable
> Date objects have been accumulated) ?

Neither of which very relevant except in the unusual and unlikely, real
long GC that is over the application defined "real-long" threshold on an
otherwise normal transaction. Note that if the transaction itself
causes GC in many cases then the additional time IS relevant to the timing.

Since the OP was going to give feedback to the user, when a transaction
takes "very long" from a human perspective, the OP can always
leave a footnote somewhere that says "Under unusual circumstances
an otherwise normal transaction may be mis-identified as excessively
long ..." with appropriate notes about what to do.

Since this is an interactive application as described, proving either
of the following is probably not worth the time to worry about:
(1) the timed activity is properly timed in all circumstances
to only include application code
and
(2) that the timing is not off by a systematic error and occasional
unpredictable random event errors (really bad unlucky GC)

-Paul

Reply to this Message

speed of reading the real time clock?

Free Magazines