0

I'm using ASM java byte code instrumentation and my goal is to measure the time in each access to a variable.

** measure time and log **

** variable access **

I'm looking for a resolution of microseconds. It should be accurate and therefore "cheap" enough (meaning that I don't want a function or a library that will take 10 ms to get the time).

I've tried System.NanoTime() (too much, and costly) and Calendar (too loose), but I'm looking for a better alternative.

Community
  • 1
  • 1
RanZilber
  • 1,840
  • 4
  • 31
  • 42
  • System.nanoTime() typically takes about 0.2 micro-seconds but I have seen it take up to 1.0 microseconds. Note: you may have to call it twice. – Peter Lawrey Feb 25 '11 at 11:25
  • Accessing a variable typically takes 1 to 30 nano-seconds depending on whether its in cache. It is very difficult to meaure this with nanoTime as its so short. Are you sure you need to measure sub micro-second events? – Peter Lawrey Feb 25 '11 at 11:27
  • @Peter Lawrey - why I might call it twice ? And well , i've done many simulations with System.NanoTime() and unfortanetly there is more then 10^3 time diffrence between each access ... which caused me to belive that microsecond is enough – RanZilber Feb 25 '11 at 11:50
  • @RanZilber, To record how long an action takes you need to time before and after the action. Like I said you are trying to record something very short and difficult to accurately record, so short its likely to not be worth recording. – Peter Lawrey Feb 25 '11 at 12:00
  • @Peter Lawrey - thanks. But,actually, my goal is to plot an heat map graph that desricbes accesses to variables within an input program throughout time. Therefore , i only need just a "relative" measure , but im not sure if mS , uS or nS is enough or good for that purpose . – RanZilber Feb 25 '11 at 12:31
  • 1
    Why not have a just the count of the number of accesses and assume the time taken is approximately the same. (Actaully it will be shorter on average (longer in total) for the most frequenetly accessed data as this is what caches are designed to do) – Peter Lawrey Feb 25 '11 at 12:37
  • @Peter Lawrey- Thats a nice point of view , but how can i assume that without turning the program to machine -depenedent? – RanZilber Feb 25 '11 at 12:52
  • 1
    Counting the number accesses shouldn't be machine dependent. AFAIK This approach is used by most profilers somewhere. – Peter Lawrey Feb 25 '11 at 12:57

2 Answers2

6

System.nanotime() is a native method call, if that is too costly for you , then you probably wont be able to find something suitable to your needs in java.

I dont think System.nanotime() will ever take 10ms (unless you specifically do something just to slow it down) to execute ever as well.

And finally, I am not sure if micro seconds will be precise enough for property access times, nanoseconds may be more useful.

fmucar
  • 14,361
  • 2
  • 45
  • 50
2

... I don't want a function or a library that will take 10 ms to get the time

Firstly, you are exaggerating. System.nanoTime() does not take 10 milliseconds.

Secondly, I don't think there is a faster way in pure Java. You might possibly be able to access a system clock faster from native code, but your code will be platform specific. (Besides, my gut feeling is that System.nanoTime() will do it as fast as possible.)

Accessing a variable may take as little as a couple of machine instruction, depending on the context and the kind of variable you are accessing. This likely to be swamped by the time taken access a system timer.

Furthermore the insertion of method calls to a clock method before a variable access may make the variable access take longer. The method call is liable to invalidate the content of registers, causing the code generator to insert instructions to refetch the variable from memory.

In short, insertion of the code to fetch the clock times is liable to give you unreliable and misleading timing numbers. You can potentially get more meaningful numbers by timing LONG sequences of instructions ... but even that can give you bogus numbers if you make mistakes in your benchmarking methodology.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216