You cannot check it with benchmarks, because behavior of this method will
vary between different JVMs, OSes and hardware. It can be different even
with the same OS depending on it's settings. Again - let's just avoid
unnecessary work. There is nothing wrong with U.currentTimeMillis() at the
On Wed, Aug 9, 2017 at 2:52 PM, Dmitry Pavlov <dpavlov....@gmail.com> wrote:
> Vladimir, could we check it using benchmarks? Internet contains a lot of
> articles about this issue. But do we know if it is still actual for new
> ср, 9 авг. 2017 г. в 14:50, Dmitry Pavlov <dpavlov....@gmail.com>:
> > It seems System.currentTimeMillis () is now in intrinsic list. This means
> > on modern JVMs performance penalty will not be so significiant.
> > Nickolay, could you please raise standalone ticket for
> > () ?
> > Could you also please check if system.nanoTime / system.currentTimeMs can
> > fix https://issues.apache.org/jira/browse/IGNITE-5963 When you create a
> > PR, I can start several run for Ignite Cache 6 suite to check if issue is
> > still reprodacible.
> > ср, 9 авг. 2017 г. в 14:41, Yakov Zhdanov <yzhda...@apache.org>:
> >> Nickolay, IgniteUtils#currentTimeMillis() is some kind of an old
> >> I guess nobody remembers when this method has been introduced. I agree
> >> that
> >> we can use System.currentTimeMillis(). I would suggest you file a ticket
> >> and replace this method calls with System.currentTimeMillis(). Sounds
> >> good?
> >> As far as reliable elapsed time measurement I agree with you that
> >> nanoTime() is better here, but it is definitely not a reason for
> >> failure, since that test is launched in single JVM on a machine that
> >> probably does not do any ntp syncs during the test to make Ignite's
> >> timeout
> >> machinery fail.
> >> Please file a ticket to switch Ignite's timeouts to nanoTime() at some
> >> point.
> >> --Yakov