• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 199
  • Last Modified:

integers vs longs vs bytes

can anyone tell me the difference in performance of these 3 types of variables?  i've read somewhere that longs are better than integers because the processor takes double the time to read an integer compared to a long.

anyways, i have no sure answer for this and would appreciate some insights from fellow developers who might know something about this.

0
janeausten
Asked:
janeausten
  • 5
  • 4
  • 2
  • +4
1 Solution
 
AllenC_JrCommented:
Integers Range From -3768 to 3767
Longs Range From -2Billion Something To 2Billion Something
Bytes Range From 0 to 255
Bytes are stored in a single 'Byte'
Integers are Stored in 2 'Bytes'
Long Integers are Stored in 4 'Bytes'

0
 
AllenC_JrCommented:
And In Performance I Would Guess that the One that Takes up the less area in bytes would increase 'Performance'
0
 
AllenC_JrCommented:
Oh and i was way wrong on Integers it is -36768 to 36767
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
MikeP090797Commented:
I've read in a VB magazie, don't remember which,  that in efficency terms LONG is fastest, then integer, and then byte
0
 
mark2150Commented:
AllenC_Jr is *STILL* wrong on range of integers. Its -32768 to 32767. aka -2^15, 2^15-1

Long range is -2^31/2^31-1 = -2,147,483,648/2,147,483,647
Byte range is -2^7/2^7-1 = -128/127

CPU runs fastest on its native word size. 8088 this would be 8 bits, 80x86 this is 16 bits, Pentium class machines 32 bits.

Long = 32 bits = fastest on Pentium machines
Integer = 16 bits = fastest on 8086/80286/80386/80486
Byte = 8 bits = fastest on 8088 (are there *ANY* of these left out there?)

M

0
 
janeaustenAuthor Commented:
hi allen,

thanks for answering, but i'm sorry i have to reject your answer and accept mark's instead.

mark, please repost your comment as an answer and i'll reward you the points.

thank you


0
 
zivfCommented:
sorry to disappoint you all 32 bit book lovers, but I have run the following code on a 166 MHz Pentium:
Sub main()
    Dim i, j, k As Long
   
    Debug.Print Timer
        For i = 1 To 10000
            For j = 1 To 1000
                k = i Mod j
            Next j
        Next i
    Debug.Print Timer
End Sub
and got the runnig time of the program 37.2 consistently, while changing only the Dim statement at top so they all will be integers (counting and computing) got a consistent timing of 36.05, so it turns out to be the answer, Integers are faster. copy and paste the code and you can check it on your computer with other data types.
Only one liitle last question: what are you doing with VB if you are interested in performance? are you planning on a native VB built database engine?
if you look for performance, better look for things that start with 'c', not in 'v'...
0
 
AllenC_JrCommented:
That is ok i didn't have Visual Basic Open so the effeciency on my answer was basically zero...
0
 
janeaustenAuthor Commented:
hi, zivf,

this is not a final rejection, i would just like to see some more opinions regarding this.  you have certainly given an alternative answer way different from mike2150.  i was going to give him the points since i had read an article similar to his answer somewhere, but now you have made me think twice.  i tried your code snippet and integers certainly are faster than longs, singles, and doubles.  singles even outperformed longs.

i think we need a tie breaker now.  i don't think i can decide between yours and mark's answers, since i'm the one asking the question, remember?  

i hope someone else can shed some light on this.

thanks
0
 
zivfCommented:
it seems to me that the compiler (VB5 compiles its files to VC5 and then uses the cl.exe) does some optimization, so if you ask for the absolute answer about how fast does it take the computer to do native code you need to write it in C. Ohterwise, you should consider testing wherever you will need more speed.
By the way: what does the app yuo build do that you take so much time for low-percentage performance calculations? Consider simply buying a faster computer, the clock-speed differences between 166 (old) and 266 (regular today) pentiums (60%) are much more to consider in such case than the difference (in %) between 36.05 to 37.2 (3.1%)
0
 
janeaustenAuthor Commented:
hi, zivf,

this is not a final rejection, i would just like to see some more opinions regarding this.  you have certainly given an alternative answer way different from mike2150.  i was going to give him the points since i had read an article similar to his answer somewhere, but now you have made me think twice.  i tried your code snippet and integers certainly are faster than longs, singles, and doubles.  singles even outperformed longs.

i think we need a tie breaker now.  i don't think i can decide between yours and mark's answers, since i'm the one asking the question, remember?  

i hope someone else can shed some light on this.

thanks
0
 
MirkwoodCommented:
Marks answer is the right one...

0
 
janeaustenAuthor Commented:
well i guess i should end this...

mark2150, please repost your comment as an answer....
0
 
davefocCommented:
Summary of previous answer and more results
Results of various experiments on the effect of variable type on the speed of execution.  The test platform was a pentium 133 machine running win95.

TEST RESULTS
ran the zizf benchmark with his dim statement (which results in running the experiment with mixed variable types), and dim statements to set variables to integer, long, variant, single and double. results as follows:

zizf bogus experiment not compiled - 31 secs
zizf bogus experiment compiled - 24 secs

integer not compiled - 11 secs
integer compiled 1 sec

long not compiled - 12 sec
long compiled - less than 1 sec

variant not compiled - 27 secs
variant compiled - 21 secs

single not compiled - 21 secs
single compiled - 9 secs

double not compiled - 22 secs
double compiled - 10 secs

ran an experiment (based on zizf benchmark) with more resolution to compare compiled long and compiled integer execution speed. results below:

Integer test - 5 seconds
Long test - 3 seconds


Ran an experiment to compare byte, integer and long performance using a simple for next loop

the long test won easily, and the byte test was significantly the slowest.

conclusions:
1) mixing types as the zizf experiment did is by far the slowest
2) compiled long and integer are very fast.  compiled long is about 40% faster than compiled integer.
3) compiling makes everything go faster
4) byte arithmetic (tested only add and subtract though) is significantly slower than integer and long arithmetic in a pentium based system.
5) variants (the default type) are really slow.



0
 
davefocCommented:
Had just one more thought (i hope) on my answer.  It is true that using long variables provides the fastest execution speed on a Pentium based machine when the compiler generates 32 bit op codes.  I think it's an open question as to whether long arithmetic would be faster if one used an earlier version of Visual Basic that used 16 bit op codes.  My bet here is that integer variable types would perform significantly better than longs even on a Pentium.  Does anybody know when VB began generating 32 bit op codes?  Incidently, all my tests were run with VB5.
0
 
janeaustenAuthor Commented:
hi dave,

well, congratulations and thanks for helping me end this. some people may think this issue doesn't matter much, but i'm quite a newbie and before this question 'bout vars i used to assign everyone of mine as VARIANT.  i thought i'd make my life simpler by doing so. =)

anne
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 5
  • 4
  • 2
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now