Menu

#109 Avoid tight while( true ) loop in Console.java while waiting for input

Unstable (example)
closed-accepted
redrum
None
5
2015-07-14
2015-07-09
No

Summary: add sleep delay to a while(true) loop in Console.java, reduces percent CPU usage noticeably when running tripleA from eclipse (on my relatively powerful machine from low 20% CPU usage to low single digits). Secondly, cosmetic changes to Console.java and add simple start of a ClientLogger.java utility class

Details:
Console.java has a while(true) loop with no sleep in it. There is a method call to block for input in the loop, but it does not look to block for very long. Measuring how often the method is called, it takes a few minutes to hit the 100's of thousands. Adding a small delay in the loop doesn't impact functionality, I've tested that we still get output to the console without noticeable update delay. After applying patch the CPU usage of tripleA when running from eclipse drops.

Specific Changes:
1 - The fix above adding the delay. Also, you'll note in the code that before we always changed the visibility of the Console window to true if it was showing. That call does stuff, so it's not free, so a second change is to always check the visibility of the window and to reveal it only if needed.

2 -some cosmetic things, Console.java does not need a stand-alone static void main test method, and some variables put into more "proper" grouping

3 - add utility class ClientLogger. Idea is to isolate for now debug level type of logging that we want to see in development but not for a user. ClientLogger perhaps can grow to do some more common logging stuff (mainly right now I want to do something about an interrupted exception, but swallowing it is bad, but so is needlessly showing a "an error occurred" window to the user.

Discussion

  •  triplelafayette

    triplelafayette - 2015-07-09

    I'll have to be more careful about the preview feature, beginning a line with "#" is not such a good thing..
    Attaching patch file.

     

    Last edit: triplelafayette 2015-07-09
  • redrum

    redrum - 2015-07-09
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -3,9 +3,9 @@
     Details:
     Console.java has a while(true) loop with no sleep in it. There is a method call to block for input in the loop, but it does not look to block for very long. Measuring how often the method is called, it takes a few minutes to hit the 100's of thousands. Adding a small delay in the loop doesn't impact functionality, I've tested that we still get output to the console without noticeable update delay. After applying patch the CPU usage of tripleA when running from eclipse drops.
    
    +Specific Changes:
    +1 - The fix above adding the delay. Also, you'll note in the code that before we always changed the visibility of the Console window to true if it was showing. That call does stuff, so it's not free, so a second change is to always check the visibility of the window and to reveal it only if needed.
    
    -Specific Changes:
    -#1 - The fix above adding the delay. Also, you'll note in the code that before we always changed the visibility of the Console window to true if it was showing. That call does stuff, so it's not free, so a second change is to always check the visibility of the window and to reveal it only if needed.
    +2 -some cosmetic things, Console.java does not need a stand-alone static void main test method, and some variables put into more "proper" grouping
    
    -#2 -some cosmetic things, Console.java does not need a stand-alone static void main test method, and some variables put into more "proper" grouping
    -#3 - add utility class ClientLogger. Idea is to isolate for now debug level type of logging that we want to see in development but not for a user. ClientLogger perhaps can grow to do some more common logging stuff (mainly right now I want to do something about an interrupted exception, but swallowing it is bad, but so is needlessly showing a "an error occurred" window to the user.
    +3 - add utility class ClientLogger. Idea is to isolate for now debug level type of logging that we want to see in development but not for a user. ClientLogger perhaps can grow to do some more common logging stuff (mainly right now I want to do something about an interrupted exception, but swallowing it is bad, but so is needlessly showing a "an error occurred" window to the user.
    
     
  • redrum

    redrum - 2015-07-14
    • status: open --> closed-accepted
    • assigned_to: redrum
     

Log in to post a comment.

MongoDB Logo MongoDB