Solved

# Long datatype faster than Integer?

Posted on 2002-05-01
621 Views
One of my co-workers says that you should always use the Long datatype in VB 32-bit because processor level operations on it run faster than Integer or Byte. He claims the reason for this is because the Integer and Byte datatypes are converted to a Long (32-bit) before the processor can work with it internal. So in short, if you're using Integer:

Integer -> Long -> perform op -> Long -> Integer

as opposed to:

Long -> perform op -> Long

Is this really true, or am I hearing BS?
0
Question by:dplambert
• 5
• 4
• 3
• +4

LVL 69

Expert Comment

ID: 6983206
I have read this in VBPJ a while back but I never give a try to that.
0

LVL 100

Expert Comment

ID: 6983226
It may be true but with today's processors I wouldn't expect any apprciable improvement in speed unless you are doing numerous integer conversions.  (Looping through a large array)

Another consideration is what will it do to memory usage?

mlmcc
0

LVL 18

Accepted Solution

mdougan earned 50 total points
ID: 6983273
The theory that I've heard is that since both Integer and Long in a i386 32-bit Windows OS are 4 bytes long, many, if not all operations that work on Integers (long or short) will implicitly convert any Integer to a Long before processing it, then convert it back.

So, coding this:

Dim x as integer
Dim i as integer

x = 5
i = 6
x = x * i

Is going to cause windows to convert x to a long, i to a long, perform the multiplication, then convert the result back to an integer.

However, if you do this:
Dim x as integer
Dim y as Long
Dim i as integer
Dim j as Long

x = 5
i = 6

y = CLng(x)
j = CLng(i)
y = y * j
x = CInt(y)

The multiplication wont have to do an implicit conversion, but since you're doing an explicit conversion (plus, in this case extra assignment statements) you'd actually be slowing things down.

The suggestion that I've heard, and follow with good results is just to never use the Integer data type in a 32-bit environment.  There is no good reason that I can see, since you're not saving any storage space.  The only time I use an Integer is if I'm calling an API or Function that requires one.
0

LVL 5

Expert Comment

ID: 6983289
it's true.

Long is better and it’s recommended by Microsoft to use long in your code.
0

LVL 5

Expert Comment

ID: 6983309
plus long is a native datatype for CPU.
0

LVL 22

Expert Comment

ID: 6983906
And what happens when you move to a 64-bit environment and all of you datatypes are defined as 32-bit longs?  And then in a 128-bit environment, they're still defined as 32-bit longs?

I think a better answer is:

Define things according to how you need them.  If you need a number that will never exceed +/-128, then use a byte.  If you need a number that will never exceed +/-32K, use an integer.  If you need a number that will hold color information, use a long.

For example, if you need something that requires 8 digits of precision, should you use a long and always divide by 10^8 after doing your calculation?  It's a lot faster!  The answer is probably NO because it is not the proper type for the job.

In other words, determine the proper type for the job and use it.  This also means that if you need speed, optimize it by using a long.

As you start moving toward newer languages in the future, I suspect that the concept of shorts, integers and longs will go away.  Instead, every data type will be either numeric or alphanumeric or some other predefined type, and the computer will optimize the space according to need.  Java is already trying to do that in its language structure.  For example, a boolean type can never be 0 or 1 because that's not boolean; it's numeric.  Rather, the only choices are true or false.  Eventually, numeric types will not have precision as part of their definition because the processor will handle it in other ways.  Instead, the precision will be part of the display.
0

LVL 5

Expert Comment

ID: 6983935
>> suspect that the concept of shorts, integers
and longs will go away.

private void Form1_Load(object sender, System.EventArgs e)
{
System.Int64 ;
System.Int32 ;
System.Int16 ;
};
0

LVL 22

Expert Comment

ID: 6983978
rkot2000, when I said "newer languages" I was referring to things 5 to 10 years in the future.  Yes, .net uses those types.  And what will happen then the 128-bit processors arrive?  Then the 256-bit processors?  Do you think a new datatype will be created for each processor?  I personally think that the whole idea will go away.  After all, how do you know when to use Int16, Int32, Int64, Int128, Int256, Int512, Int1024, Int2048, Int4096?  After a while, it not only becomes silly, but actually becomes confusing.
0

LVL 5

Expert Comment

ID: 6984230
10 years ago we DOS and different priorities/problems

dplambert, try this code(you need to add one listbox and 2 buttons :

on my pc int ~ 1400
lng ~ 500

Option Explicit

Private Declare Function GetTickCount Lib "kernel32" () As Long

Private Sub Command1_Click()
Dim i As Long
Dim j As Integer
Dim k As Integer
Dim p As Integer
Dim start1 As Long
Dim end1 As Long

start1 = GetTickCount

For i = 0 To 100000000
j = 500
k = 459
p = j + k

Next i
end1 = GetTickCount
List1.AddItem "Integer - " & (end1 - start1)

End Sub

Private Sub Command2_Click()
Dim i As Long
Dim j As Long
Dim k As Long
Dim p As Long
Dim start1 As Long
Dim end1 As Long

start1 = GetTickCount

For i = 0 To 100000000
j = 500
k = 459
p = j + k

Next i
end1 = GetTickCount
List1.AddItem "Long - " & (end1 - start1)

End Sub

Command1.Caption = "Int"
Command2.Caption = "Long"
End Sub
0

LVL 22

Expert Comment

ID: 6984366
>10 years ago we [had] DOS

Good point.

Your tests prove that longs are FASTER than integers, but do not prove that they are better.  And as I point out, what will happen when you move that code to a 64-bit system?  Will the ints still be 3x slower?  They may in fact be quicker because the parser needs to split apart only 2 bytes rather than 4 bytes before reassembling them into 8 bytes.

I still say, "Use the proper choice for the job.  If there is not "proper" choice, then use what is currently the fastest with an understanding that it may be slower next year."
0

LVL 3

Author Comment

ID: 6984553
From what I've read above, it's no doubt that Long is faster than Integer/Byte in terms of processing speed. So if you're making something intense like an action game, you should definitely use Long. However, most applications out there probably won't realize much benefit in terms of speed.

I think that a decade ago, variable sizes were a big deal because memory was a bigger concern. I remember working on my Commodore 64 - you could hit that RAM ceiling real quick unless you carefully picked your data types. Now, memory is cheap and in bulk so that most programmers don't have to worry about even 100k being used.

From a conceptual viewpoint, the distinction between Byte/Integer/Long is important. If I have a variable that can hold values 0-10, then by the textbook, I should use Byte. In terms of design, especially from the non-programmers viewpoint, this is important. Why have Hungarian notation if all of your numbers are lngNumber? It helps to put scope on what these variables are doing.
0

LVL 22

Expert Comment

ID: 6984704
Good comments, dplambert.  To re-inforce that, which is faster: longs or boolean?  If the answer is long, then why bother having boolean at all?  The answer is scope.

If all you care about is speed, then why bother even having boolean, byte, short or integer in your dev environment?  Integer may be okay for backware compatibility, but boolean was introduced AFTER longs already existed, and shorts only exist at the moment in VB.NET.
0

LVL 15

Expert Comment

ID: 6984761
Here is my word (=2 bytes):

Use Longs for any integer calculation.
The only exception to that is: use Integers if they are already defined in events and controls (e.g. for Index in control array events) and
to save memory if you have big Integer array.

>that can hold values 0-10, then by the textbook, I should use Byte

Don't use Byte - it was *never* intended to be used for any calculation; only comparison operation works OK for Byte data type.  Use Byte if you have big array and storage is important.

Did ya know:

Long is the only data type that allows using CPU registers - For...Next loop which uses Long can be many times faster than loop which uses Integer.

Computation: "lngThis / lngThat" is not:
Longs -> perform op -> Long
but:
Longs (32-bit integers) will be first converted to floating point (Double) -> perform op -> and result will be converted back to Long.
0

LVL 3

Author Comment

ID: 6986426
So who gets the points?
0

LVL 22

Expert Comment

ID: 6986459
Well, that's up to you.  Locate the comment that was the most helpful to you and accept it as your answer.  If several were equally helpful, either accept one here and add another question in this topic area entitled something like, "Points for xxx", or add a zero-point question in the customer support area (referenceing this Q) and asking for the CS people to split the points however you see fit.
0

LVL 3

Author Comment

ID: 6986634
It's only a 50 pointer, otherwise I'd split it...
0

## Featured Post

Introduction While answering a recent question about filtering a custom class collection, I realized that this could be accomplished with very little code by using the ScriptControl (SC) library.  This article will introduce you to the SC library a…
Most everyone who has done any programming in VB6 knows that you can do something in code like Debug.Print MyVar and that when the program runs from the IDE, the value of MyVar will be displayed in the Immediate Window. Less well known is Debug.Asse…
Get people started with the process of using Access VBA to control Excel using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Excel. Using automation, an Access application can laun…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…