In many cases, we actually need a proper timestamp (for example for
timestamps in streaming records).
I just ran a small micro-benchmark (Java 8, Linux kernel 3.11, 64bit VM)
Making 5,000,000 function calls
System.currentTimeMillis() took: 13240msecs
System.nanoTime() took: 13355msecs
At least o
A big part of the cost of currentTimeMillis() is that it does a lot of work
to make sure that the time is really time.
If you only need a monotonic timer, nanoTime() might be what you want
instead of currentTimeMillis(). nanoTime() is particularly handy when you
want to avoid issues to do with le
Hi!
Nice idea.
It would be good to have this implemented as a kind of service that
components can "acquire".
A component that needs time can do something like "Clock clock =
ClockService.aquire()", which increments a reference count in the central
clock service and starts the thread if it has no
Thank you Fengbin Fang for doing this microbenchmark!
The numbers clearly show that your approach is a lot faster.
I'm curious if this does also affect the performance of a complete data
flow.
Looking forward to your results,
Fabian
2015-08-13 8:35 GMT+02:00 Fangfengbin :
> Hello!
>
> I have a
Hello!
I have a test about cost of System.currentTimeMillis() and my
CLOCK.currentTimeMillis() .( My clock will be a JVM singleton)
Call currentTimeMillis function 1 times, System.currentTimeMillis()
need about 1902ms and my CLOCK.currentTimeMillis() only need 119ms.
The function perfor
