Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Is System.currentTimeMillis() call costly  RSS feed

 
Thyagarajan Kathirvelu
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ,

I am new to java. To impement a delay of 5 s in my code I used the below code snippet instead of Thread.sleep.

Will the below code cause major performance overhead to the JVM. Is the System calls costly?

 
Ireneusz Kordal
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Runt this code and observe CPU utilization.
Then run the code with sleep method and observe the same.
You will see the difference.

On 4-core machine you probably don't notice any delay,
but on single core the computer could even hang for 5 seconds.
 
Thyagarajan Kathirvelu
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the response.

This code was executed in a machine having 2 Quad core CPU. A test was executed for the entire application which had this code snippet. The cpu utilisation was not high but the performance of the entire application came down. There can be around 20 threads doing the while loop.

Is the slowness caused because of invoking the System.currentTimeMillis() for 5 seconds non.stop. I know it is not the best way to implement a delay, but would like to understand which part of the code snippet is costly and why? Why would CPU hang for 5 s?

Sorry for asking very basic questions..

Thanks in advance.
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


What you have written is a "spin wait" -- it will take one CPU, and spin it (to 100 percent utilization), until the wait time is encountered.

Basically.... don't do this.

Henry
 
Campbell Ritchie
Marshal
Posts: 55717
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

Your code will be much easier to read if you use the code button; I shall edit your post and you can see how much better it is. I shall move this thread as too difficult for "beginning Java".

If you are single-threading you will probably not notice a performance overhead, but what you are doing is making the JVM loop repeatedly instead of a simple delay, so that will probably be much more expensive on JVM and CPU resources.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's also possible the JIT will optimize such loops away: you should never rely on a busy loop for timing.
 
Kees Jan Koster
JavaMonitor Support
Rancher
Posts: 251
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear Thyagarajan,

What is wrong with Thread.sleep()?

Kees Jan
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Think of a child in the back seat of a car who keeps poking the driver and asking "are we there yet?" And the child does nothing else, just keeps repeating that one action over and over and over. The driver receives nothing but constant interruptions. That's what the code above is doing.

Put another way: there's nothing inherently costly about System.currentTimeMillis(). It's pretty fast, especially compared to the 5-second wait you're attempting to generate. But if you do it over and over and over and over... and do nothing else, then sure, it will take up a lot of time. Almost any other code inside that loop would create a similar effect - unless it's code which is designed to give up the processor when it has nothing useful to do. That's where Thread.sleep() would be useful. That's all you need, here. In other applications, methods like wait() in Object might be useful. Most I/O classes will gracefully give up CPU cycles whenever there's nothing for them to do because there's no new input to process. Most other well-designed libraries will do the same whenever something outside their control is temporarily preventing them from doing something.
 
Thyagarajan Kathirvelu
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot for all your replies. It was very helpful to me.

It was certainly a bad choice to use while loop to implement a delay instead of using Thread.sleep.

 
Campbell Ritchie
Marshal
Posts: 55717
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote:Think of a child . . . who keeps . . . "are we there yet?" . . .
No child ever does that. It's
Are we nearly there yet?
And, thank goodness, my daughters never did that.
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 37241
519
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Mike Simmons wrote:Think of a child . . . who keeps . . . "are we there yet?" . . .
No child ever does that. It's
Are we nearly there yet?
And, thank goodness, my daughters never did that.

Country difference? Where I live "are we there yet" is the expression.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I found Campbell's certitude about that to be rather amusing.
 
Campbell Ritchie
Marshal
Posts: 55717
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote: . . . rather amusing.
At least there's something amusing to "are we [nearly] there yet/"
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!