Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > speed of reading the real time clock?

Reply
Thread Tools

speed of reading the real time clock?

 
 
bugbear
Guest
Posts: n/a
 
      05-16-2006
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 With Quote
 
 
 
 
=?ISO-8859-15?Q?Tobias_Schr=F6er?=
Guest
Posts: n/a
 
      05-16-2006
Hi,

bugbear schrieb:
> 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
 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      05-16-2006
bugbear wrote:
> 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 With Quote
 
bugbear
Guest
Posts: n/a
 
      05-16-2006
Robert Klemme wrote:
> bugbear wrote:
>
>> 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.


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 With Quote
 
Alex Hunsley
Guest
Posts: n/a
 
      05-16-2006
bugbear wrote:
> 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 With Quote
 
Thomas Weidenfeller
Guest
Posts: n/a
 
      05-16-2006
Alex Hunsley wrote:
> 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
--
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/...g/java/gui/faq
http://www.uni-giessen.de/faq/archiv....java.gui.faq/
 
Reply With Quote
 
Thomas Fritsch
Guest
Posts: n/a
 
      05-16-2006
Thomas Weidenfeller wrote:
>
> 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) ?

--
Thomas
 
Reply With Quote
 
P.Hill
Guest
Posts: n/a
 
      05-21-2006
Thomas Fritsch wrote:
> Thomas Weidenfeller wrote:
>
>>
>> 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 With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Ok time to do a partition (system) back up, for real this time.suggestions please squirlchatr@yahoo.com Computer Support 2 04-22-2009 10:42 AM
Real Time Midi File Playback - Reading and Writing midi at the sametime Gilly Python 6 05-04-2008 09:16 PM
Is time.time() < time.time() always true? flamesrock Python 8 11-24-2006 06:51 AM
speed speed speed a.metselaar Computer Support 14 12-30-2003 03:34 AM
Real time converted to Unix time Brian Perl Misc 1 08-29-2003 04:36 AM



Advertisments