speed of reading the real time clock?

B

bugbear

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
 
?

=?ISO-8859-15?Q?Tobias_Schr=F6er?=

Hi,
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

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
 
R

Robert Klemme

bugbear said:
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
 
B

bugbear

Robert said:
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.

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
 
A

Alex Hunsley

bugbear said:
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).
 
T

Thomas Weidenfeller

Alex said:
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
 
T

Thomas Fritsch

Thomas said:
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) ?
 
P

P.Hill

Thomas said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top