none
Which are quicker, constants or literals? RRS feed

  • Question

  • I have a function which carries out some bitwise comparisons on bytes read in from a file. The examples below are cut-down versions of the real thing, to keep things simple.

    I can think of three subtly different approaches to representing the values and I was wondering which should technically be the quickest, considering (amongst other things) the conversion between Bytes and Integers, if this function were to be called millions of times. It's a hypothetical question but I always aim to write the fastest code that I know how, so it would be great to get an expert's opinion.

     ' Approach 1
    
     Private Function MyFunction(b() as Byte) as Boolean
      Return b(0) And 31 AndAlso b(1) And 128 AndAlso b(2) And 128
     End Function
    
    ' -----------------------------------------------
    
     ' Approach 2
    
     Private Function MyFunction(b() as Byte) as Boolean
      Return b(0) And CByte(31) AndAlso b(1) And CByte(128) AndAlso b(2) And CByte(128)
     End Function
    
    ' -----------------------------------------------
    
     ' Approach 3
    
     Private Const byt31 As Byte = CByte(31)
     Private Const byt128 As Byte = CByte(128)
    
     Private Function MyFunction(b() as Byte) as Boolean
      Return b(0) And byt31 AndAlso b(1) And byt128 AndAlso b(2) And byt128
     End Function
    
    

    They all work, of course, but I have the feeling that the third approach might run the fastest.

    Any ideas? Thanks in advance. ;)

     

    Alec

    Wednesday, March 23, 2011 9:09 PM

Answers

  • 1 and 3 should be functionally identical, as a constant is just replaced by the compiler at compile time.   Option two will likely be (microscopically) slower, as it requires some extra instructions for the CByte conversion operation.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by SP1R1TM4N Wednesday, March 23, 2011 11:09 PM
    Wednesday, March 23, 2011 10:01 PM
    Moderator
  • I know I'm nit-picking, but I thought there might be a difference because of narrowing or widening in 1, which surely adds a few nanoseconds every time. Storing 31 and 128 as bytes from the start should be marginally quicker, wouldn't you think?

    The compiler does these optimizations for you.  It's going to store this directly as a byte since your directly assigning byte data.

    (You can tell I hark from the days of the Z80, when considerations such as these may have had some significance, so if I'm being too pedantic about this just don't reply, and I'll mark your response as an answer in a little while.)

    Regards,

    Alec ;)

    These differences are, realistically, insignificant.  This is a perfect case of "premature optimization" - you're much better off just picking the version that is the most readable in your eyes, and not worrying about the performance.

     

    (That isn't to say that perf. isn't important - I'm 100% about performance, but real, meaningful optimizations happen on an algorithmic level, not on an opcode level...)

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by SP1R1TM4N Wednesday, March 23, 2011 11:10 PM
    Wednesday, March 23, 2011 11:00 PM
    Moderator

All replies

  • 1 and 3 should be functionally identical, as a constant is just replaced by the compiler at compile time.   Option two will likely be (microscopically) slower, as it requires some extra instructions for the CByte conversion operation.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by SP1R1TM4N Wednesday, March 23, 2011 11:09 PM
    Wednesday, March 23, 2011 10:01 PM
    Moderator
  • Thanks for the prompt response, Reed.

    I know I'm nit-picking, but I thought there might be a difference because of narrowing or widening in 1, which surely adds a few nanoseconds every time. Storing 31 and 128 as bytes from the start should be marginally quicker, wouldn't you think?

    (You can tell I hark from the days of the Z80, when considerations such as these may have had some significance, so if I'm being too pedantic about this just don't reply, and I'll mark your response as an answer in a little while.)

    Regards,

    Alec ;)

    Wednesday, March 23, 2011 10:24 PM
  • I know I'm nit-picking, but I thought there might be a difference because of narrowing or widening in 1, which surely adds a few nanoseconds every time. Storing 31 and 128 as bytes from the start should be marginally quicker, wouldn't you think?

    The compiler does these optimizations for you.  It's going to store this directly as a byte since your directly assigning byte data.

    (You can tell I hark from the days of the Z80, when considerations such as these may have had some significance, so if I'm being too pedantic about this just don't reply, and I'll mark your response as an answer in a little while.)

    Regards,

    Alec ;)

    These differences are, realistically, insignificant.  This is a perfect case of "premature optimization" - you're much better off just picking the version that is the most readable in your eyes, and not worrying about the performance.

     

    (That isn't to say that perf. isn't important - I'm 100% about performance, but real, meaningful optimizations happen on an algorithmic level, not on an opcode level...)

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by SP1R1TM4N Wednesday, March 23, 2011 11:10 PM
    Wednesday, March 23, 2011 11:00 PM
    Moderator

  • (That isn't to say that perf. isn't important - I'm 100% about performance, but real, meaningful optimizations happen on an algorithmic level, not on an opcode level...)


    Okay, I'll buy that. Thanks again!

    Alec

    Wednesday, March 23, 2011 11:09 PM