speed of reading the real time clock?

Discussion in 'Java' started by bugbear, May 16, 2006.

  1. bugbear

    bugbear Guest

    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
     
    bugbear, May 16, 2006
    #1
    1. Advertising

  2. 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
     
    =?ISO-8859-15?Q?Tobias_Schr=F6er?=, May 16, 2006
    #2
    1. Advertising

  3. 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
     
    Robert Klemme, May 16, 2006
    #3
  4. bugbear

    bugbear Guest

    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
     
    bugbear, May 16, 2006
    #4
  5. bugbear

    Alex Hunsley Guest

    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).
     
    Alex Hunsley, May 16, 2006
    #5
  6. 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/computer-lang/java/gui/faq
    http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
     
    Thomas Weidenfeller, May 16, 2006
    #6
  7. 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
     
    Thomas Fritsch, May 16, 2006
    #7
  8. bugbear

    P.Hill Guest

    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
     
    P.Hill, May 21, 2006
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pieter Hulshoff
    Replies:
    0
    Views:
    1,062
    Pieter Hulshoff
    Aug 13, 2003
  2. Chris Pruett
    Replies:
    0
    Views:
    1,435
    Chris Pruett
    Aug 14, 2003
  3. Replies:
    8
    Views:
    495
    Magnus Lycka
    Aug 5, 2005
  4. Peter Hansen
    Replies:
    0
    Views:
    727
    Peter Hansen
    Feb 22, 2006
  5. Peter Hansen
    Replies:
    0
    Views:
    621
    Peter Hansen
    Feb 22, 2006
Loading...

Share This Page