[ghqwerty]

Ok so i have a fully working function which i'm just trying to optimize right now.

currently i have the following few lines in my code

 
c = a + b + remainder

Where a and b are < 10 and remainder is an integer of value 0 or 1.

I got to thinking if it would be faster storing remainder as a boolean and then doing

If remainder Then 
c = a + b + 1
else
c = a+b
End If

This is part of my string addition script which adds big number in string format together. It's already ridiculously fast for small numbers and the variation of bool and int makes little visible difference.

However, for 2 numbers with > 300 digits+decimals it seems to run in about a THIRD of the time.
Original runtime ~19ms
with bool 'variation' ~ 6ms

So i'm posting this to see if somebody could explain the huge difference in speed, and also as a pointer to other people who might be in the same situation.

[demausdauth]

If you use an integer and then put that value in a situation where it can/would be converted to a boolean value, then VB can and will implicitly convert it for you. However, this is at the expense of converting the integer to a boolean and then processing the if statement. Whereas if you are outright using a boolean type then there is no need to do the conversion.

[birty]

At first, the result seemed counter intuitive because you had added an if branch (which potentially defeats the 'CPU branch prediction' logic increasing CPU stalling in bottleneck routines). However then I noticed from your comment that a and b are strings.
Concatenating strings is notoriously slow in bottleneck routines. Each concatenation (+ operator) in the statement incurs another memory allocation overhead. The speedup is because some of the time, you are now only concatenting two strings, not three. It is interesting that there seems to be a bigger than expected additional overhead from concatenating two long strings to concatenating three strings, implying the performance of subsequent string (+) operations in the same statement gets worse and worse and worse.

It is good practice to use System.IO.StringBuilder when several concatenations are involved in a bottleneck routine, as this allocates a single block of memory (a buffer) 'up front' then is populated with subsequent calls to 'Append'. When finished appending, simply call the ToString method to get a copy of the string you just built. To 'reset' a stringbuilder in a loop, simply set the Length to zero, so you can reuse the same stringbuilder memory buffer again.

[lar3ry]

This is part of my string addition script which adds big number in string format together.

Your question reminded me of a machine IBM made, many years ago. The IBM 1620. We used to call it CADET, which stood for Can't Add, Doesn't Even Try.

It could, however, make use of a scheme that was actually a clever table lookup. The table was based at a fixed address, and in order to add, the digits were fetched one at a time, starting with the lowest order ones, in pairs. The digits were stored in the two decimal digit positions after the table's base, and then the table was accessed at the address formed. At that address, was the sum of the two digits, and a flag bit that indicated a carry. The carry was remembered for the next fetch. There's a Wikipedia article on the 1620.

' Example: 94 + 255
      ' Assuming the table resides at address 400
      '   Table address = 445     (two lowest order digits)
      '    at that address we find 9  (no flag)
      '   Table address = 495
      '     at that address we find 4 (with flag)
      '   Table address 402  (no more digits in first number)
      '     at that address we find 2, and remember the carry, so incrment

I have occasionally thought it might be intersting to write this in a modern language.