-3

I wonder about my program speed. When I use methods like Array.GetLength(1) or so it always returns int variable. Or when I insert a single number the compiler declares it as int again. Do I need to convert them to byte variables to lower the memory usage or this will affect my program speed?

Aleksandar Seferinkin
  • 63
  • 5
  • 1
    possible duplicate of [Should I use byte or int?](http://stackoverflow.com/questions/2346394/should-i-use-byte-or-int) (or [Why should I use int instead of a byte or short](http://stackoverflow.com/questions/1097467/why-should-i-use-int-instead-of-a-byte-or-short-in-c-sharp?lq=1) or [Does using small datatypes reduce memory usage](http://stackoverflow.com/questions/6198240/does-using-small-datatypes-for-example-short-instead-of-int-reduce-memory-usag)) – Tim Schmelter May 12 '13 at 21:30
  • The easiest way to answer this question is to profile both variances – Kirill Bestemyanov May 12 '13 at 21:30
  • fastest size is your native size. 32 bit os? then it is int. 64 bit os? can be "long" – huseyin tugrul buyukisik May 12 '13 at 21:31
  • 3
    i think, the most important question is: "do you really need this micro optimizations?" You don't work on a 64K machine with 4.77MHz CPU – I4V May 12 '13 at 21:31
  • 2
    For method variables, `byte` vs `int` won't make the slightest difference whatsoever; IL stack ops only really exist for i8/i4 - i2 and i1 are implemented as i4. If you had an array of 20,000 `int` vs 20,000 `byte`, then *that* might be a worthwhile question. – Marc Gravell May 12 '13 at 21:32

2 Answers2

4

Both are equally fast as far as arithmetic operations the computer performs on them.

But if you have a large amount of data then byte can be significantly faster, purely because of the smaller size:

  1. Your CPU cache holds more byte objects than int objects.
  2. Using every element of an array of byte objects needs less memory bandwidth than int objects. If you have to use a database or send the data across a network this use of bandwidth becomes a really big deal.
  3. Your computer RAM can hold more byte values before it starts having to use the hard disk as virtual memory. If your data set was a size where int would need virtual memory and byte would not, then byte will be a lot faster.

The only real downside of bytes is that you end up writing code to convert to and from int often, even if this conversion ends up being done for free on the CPU (using a byte transfer to register instead of a word transfer)

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
4

Method variables are on the stack (caveat: iterator blocks, captured variables, etc - but don't worry about those). The stack is going to be the same size no matter what you do. If you were talking about grossly over-sized value-types, then the obvious concern would be stack exhaustion (which could perhaps be mitigated via ref, but that is not related to this question) - but changing local method variables from int to byte will not change anything. In fact, IIRC the IL stack operations are only defined in terms of 4 or 8 byte values.

Basically: this won't help at all, so don't worry about it. But it also isn't even remotely impacting your application's performance or memory usage. If you want to know what is, then profile.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • As an illustration - see the comments on `conv.ovf.u1`, one of the opcodes that casts to a `byte` (specifically, in a `checked` context): "Convert to an unsigned int8 (on the stack as int32) and throw an exception on overflow." - even though it logically converts to `int8`, it is *immediately* actually an `int32` again. What this *actually* does is lop off all except the LSB (checking for overflow), but leave it as an `int32` – Marc Gravell May 12 '13 at 21:42