Cost of System.currentTimeMillis?

[Erik Svensson]

Howdy folks!

Me and a colleague are right now working on a data stream intake from Interactive Data through a CSP (their client on-site machine). We get quite a lot of data (20 MB/s) and my colleague is starting to
wonder about the cost for time stamping each message with a System.currentTimeMillis() call which is what we do right now.
His doubts got me wondering. It used to be that the word on the street was that the currentTimeMillis() was really expensive but when I check around right now I find that that is not the common wisdom any more.
My colleague has implemented a complex and wonderful heap of code to update the timestamp only when needed but this is based on the traffic we receive and so it is not deterministic in a comfortable way.
What is the best way todo this, really?

Cheers
Erik Svensson

[Vitaly Davidovich]

Some good news (assuming you're on recent linux kernel):

1) System.currentTimeMillis() is an intrinsic to the JIT, so there's no JNI overhead.

2) The intrinsic emits a call into libc's gettimeofday function.

3) linux provides a fastpath to a few kernel functions that doesn't cause a user-to-kernel mode switch (known as vsyscall and vDSO) -- gettimeofday is one of them.

So the above means there's minimal *overhead* at getting to the source of the value; the source of the value is a counter that the kernel maintains on its own interrupt (and may be adjusted for things like NTP and so on) schedule.  So in short, this is pretty cheap on its own.  Whether it imposes some penalty for your scenario, hard to say -- you can try a simple microbenchmark to see how many of these calls you can make in compiled code, and then determine if the cost warrants whatever your colleague did instead.

Erik Svensson

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aleksey Shipilev]

See this piece about System.nanoTime():

 http://shipilev.net/blog/2014/nanotrusting-nanotime/

I think it generally applies to System.currentTimeMillis as well,

but since my post was about System.nanoTime, it did not bothered

to follow-up. However, the original benchmark project still measures

the currentTimeMillis costs:

  https://github.com/shipilev/timers-bench

The data I've got from multiple sources is that currentMillis actually 

scales pretty well, sometimes much better than nanoTime, but at the 

expense of much, much higher granularity. That seems to be because

the timer value that backs the syscall for current time is actually updated

by OSes themselves.

-Aleksey.

Erik Svensson

[punx120]

Hi Vitaly, what would you consider a "recent linux kernel", 3.x?

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Vitaly Davidovich]

I can't seem to find the exact kernel release where this appeared, but I think it was in the latter 2.6.x range; 3.x is definitely recent enough.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Erik Svensson]

Thanx all, interesting info. 

I will run the benchmark on a production look-alike and see what it looks like. In production I’m forced to run on a virtualized platform so we’ll see what falls out.

I can add (about virtualised platform) that the cost of swapping in that environment is through the roof, even for small amounts of swapping. We’re talking seconds in added latency.

cheer

Erik Svensson

[Viktor Szathmáry]

Hi,

I have found on virtualized (e.g. EC2) instances, the default xen clocksource is extremely slow for nanotime (to the point where basic profiling calls had a measurable impact on overall application performance). Setting it to TSC does the trick:

echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource

Regards,

 Viktor

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.