• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

What is Overhead?

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I came across below statement from a Java book:

Owing to performance considerations, primitive data type values are not objects in Java. Because of the overhead of processing objects, the language’s performance would be adversely
affected if primitive data type values were treated as objects

Does the presence of a try-catch block impose overhead when no exception occurs?
No



  • What is overhead?


  • Why "overhead of processing objects, the language’s performance would be adversely affected if primitive data type values were treated as objects" ?


  • why "presence of a try-catch block" does NOT impose overhead when no exception occurs? Does this mean it imposes overhead when exception occurs and why?


  • I'm a beginner programmer. Please explain me in simple terms.

    Thank you.
     
    Marshal
    Posts: 26523
    81
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    "Overhead" is work that has to be done, but which is not directly related to the task at hand. For example if you rode your bike to work, then having to take the bike to a special security cage and get out your employee card and tap it on the door to allow you to store your bike securely would be "overhead" for your getting-to-work task. And in Java, if you stored your int values as objects, and you wanted to add two of them, then having to convert the two objects to primitives before adding and converting the result back to an object afterwards would be "overhead".

    I leave it to you to determine what kinds of "overhead" might be associated with try-catch blocks. Let us know what you think.

     
    milind k das
    Greenhorn
    Posts: 17
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Clapham wrote:

    I leave it to you to determine what kinds of "overhead" might be associated with try-catch blocks. Let us know what you think.



    Hello Paul. Thank you for responding. Here's why try catch block will not impose overhead when no exception:

    When there is no exception, the statements in try block will executed as normal without executing catch block. - Not confident on this answer :)

    When there's exception in try catch block, I think there will be no overhead. Because, for exception which are not of "Error" or "RuntimeException" classes or their subclasses, the method with try catch block will need throws statement in method signature and catch block exceptions handling.

    When the exception is not handled in catch block, control goes to caller of method looking exception handler in that method and cycle keeps going until respective exception handler of exception is found. But this expected way of execution. This cannot be overhead.


    Please share your thoughts on this.
     
    Paul Clapham
    Marshal
    Posts: 26523
    81
    Eclipse IDE Firefox Browser MySQL Database
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    milind k das wrote:why "presence of a try-catch block" does NOT impose overhead when no exception occurs? Does this mean it imposes overhead when exception occurs and why?



    That all sounds reasonable to me. Although I suppose some might argue that the work required to catch an exception isn't part of the task to be performed; I'm happy with your idea that it is part of the task. But let me just mention a logic error which you made in your original post.

    The hypothesis is that "no exception" => "no overhead". We're assuming that's true. However from that true statement it does not logically follow that "exception" => "overhead". That's the converse of the original statement and it's not equivalent to it. So no, it doesn't mean that.

    (It does mean, though, that "overhead" => "exception", which is the contrapositive of the original statement, is true because the contrapositive is equivalent to the original statement. That would be something like "if there's overhead then it's because there was an exception.")
     
    milind k das
    Greenhorn
    Posts: 17
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I kind of understood but bit confused. I study through more. May I request for an example of "if there's overhead then there's exception". It will help me understand better. Thanks again.
     
    Saloon Keeper
    Posts: 12878
    279
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Be careful, this post is about formal logic and won't help you with your original question. Paul means the following:

    We assume that the statement "no exception implies no overhead" is true. Regardless of whether it really IS true, we just make the assumption that it is true on the basis that we trust what the book says.

    I underlined the word "implies" in the statement above, because it has special meaning in mathematical logic. Instead of "implies", we can also use the material implication operator "→" and the statement becomes "no exception → no overhead".

    The operator means: If the statement on the left side is true, then the statement on the right side must also be true.

    It does NOT mean: If the statement on the right side is true, then the statement on the left side must be true. This is the converse of the original statement, and as Paul explained, it does not follow from the original statement logically. You asked "Does this mean it imposes overhead when exception occurs" and the answer to that question is "no", because the converse of a true statement is not automatically also true.

    However, there is a rule that says that if a statement is true, its contrapositive is also true.

    We get the contrapositive of the original statement by negating the statements on the left and the right side of the material implication operator, and then swapping the direction of the implication: "not no overhead → not no exception", or "overhead → exception".

    Just by using logical operations, we can interpret the original statement in two ways:

  • If there is no exception, there must be no overhead. (This is what the book says)
  • If there is overhead, there must be an exception. (This logically follows)

  • Note that the second of these is different from what you asked.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 12878
    279
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Let back away from formal logic and go back to the original post.

    Java is designed in such a way that you don't get a performance penalty for wrapping a piece of code in a try-statement:
    has exactly the same performance as just:

    The performance penalty (also known as overhead) comes from catching exceptions. The reasoning is as follows: "An exception indicates an exceptional situation and should not occur frequently. Therefore, the performance characteristics of the exception handler are not important and usually typically poor". In practice, this means that you should not rely on catching exceptions as part of the regular execution path through your code. For instance, programmers sometimes write code similar to this:

    This is a bad idea, because a user entering invalid input is NOT an exceptional situation, but rather something that occurs relatively frequently.

    You should not deal with this situation by catching an exception, but rather by using regular logic:
     
    milind k das
    Greenhorn
    Posts: 17
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hello @Stephen,

    Thank you very much for responses. It gave me good understanding on the topic. I have quick question which not related to this topic.

    Consider below code:



    I'm unable to import A1 class. The Problem_12_02 is in different package. All classes have public modifier. Why am I not able to import the public class in different package?
     
    Paul Clapham
    Marshal
    Posts: 26523
    81
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Your class A1 is not in a package, or as Java says, it's in the "default package". Classes which are in a named package, like your class Problem_12_02, cannot import classes from the default package, hence the error message.

    You could fix that by putting class A1 into a named package.
     
    milind k das
    Greenhorn
    Posts: 17
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Clapham wrote:

    You could fix that by putting class A1 into a named package.



    May I know how we can access class from different packages? I thought public modifier gives access across the packages.
     
    Paul Clapham
    Marshal
    Posts: 26523
    81
    Eclipse IDE Firefox Browser MySQL Database
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    milind k das wrote:May I know how we can access class from different packages? I thought public modifier gives access across the packages.



    You already know that. Your Problem_12_02 class does exactly what it needs to do. The only problem is that A1 isn't in a package, and I already explained how you should fix that.
     
    milind k das
    Greenhorn
    Posts: 17
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Clapham wrote:

    You already know that. Your Problem_12_02 class does exactly what it needs to do. The only problem is that A1 isn't in a package, and I already explained how you should fix that.



    Yes. I see when I moved it into package it's working fine. May I know what "default package" restrictions are? The path of class which was in default package is src>main>java. Does this mean access modifiers doesn't apply to default directory? Sorry if my question is repeat. I'm still beginner.
     
    Paul Clapham
    Marshal
    Posts: 26523
    81
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    milind k das wrote:May I know what "default package" restrictions are?



    You can't import a class from the default package.
     
    reply
      Bookmark Topic Watch Topic
    • New Topic