Genre: Forum

But is there much of a performance hit when using Double instead of Long? Reading that link you provided, a Long is 4 bytes long while a Double is 8 bytes long. There is a significant performance hit when using Double (or Single), not because of the different number of bytes but because Doubles are floating point and use a different representation. Longs are just simple binary numbers and are much more straight forward to process. However it depends on what you are doing as to whether it really matters to your application. If you are doing massive, complex calculations where a large part of the processing time is spent just calculating then it will make a big difference, but if it's just displaying a simple screen or reading a few rows from a database etc you won't notice any difference at all. Will there be much of a performance hit when using a Double instead of a Long variable type? I wouldn't worry about it too much. I know the purist's will come down on me for saying this, but the reality is you can spend a lot of time writing code that will be really efficient in order to save a couple of milliseconds and maybe a meg or two of RAM. I would rather see that development time go towards better application testing and documentation. If you are writing something that is computationally arduous, you should probably use a lower level language like C++ as opposed to Visual Basic. You really don't want to store integer data as a floating point number, as this will lead to a variety of problems with inaccuracy. Of course not. I was just trying to think of a way that earlier statement could be justified, that a Variant is slower with respect to a Double than it is to a Long :-) I would really hope MS had designed the Variant type so that it could store both an integer value and a floating-point value at the same time. It's interesting to consider how other languages solve this problem. Perl variables, for instance, contain separate IV, NV, PV (integer, numeric, pointer value) slots, and there's a bunch of flags to indicate which slots contain valid values, whether the IV is actually unsigned, etc. Variants can hold almost any type of data, including objects. In VB6 you should almost never use Variants unless there are specific reasons why you need to (e.g. you are writing a COM component that needs to be called late-bound and that has by-reference parameters). Not only is the overhead excessive, unless you specifically convert the variants to a particular type in your code then you have no control over how the runtime treats them when doing calculations and comparisons etc. The decision as to which numeric data type you should be based on the business logic, not performance. If you only need to store integers that will fit in 4 bytes use Long (Int is not really any faster than Long on modern processors). If you need to store floating point numbers (i.e. decimal fractions) other than money use Double, or Single if you are sure that the accuracy and/or size required are compatible with Single. If you need to store money use Currency (aka decimal). Of course if you are storing your data in a database then obviously you need to take into account what data type is used in the database, in which case you don't really have a choice at the VB6 level. Hmm, yeah, I think you're right. It appears that in VB6 the "decimal" datatype is just an odd kind of Variant. Probably should avoid it. How about Currency? Also, doesn't VB6 come with online help? Surely you can find out these kinds of things just by looking through that? The help that came with it is now even more valuable, since Microsoft no longer have it on their website! Edit: Just dug out some old MSDN library CDs: Note At this time the Decimal data type can only be used within a Variant, that is, you cannot declare a variable to be of type Decimal. You can, however, create a Variant whose subtype is Decimal using the CDec function. Currency (scaled integer) 8 bytes -922,337,203,685,477.5808 to 922,337,203,685,477.5807 Decimal 14 bytes +/-79,228,162,514,264,337,593,543,- 950,335 with no decimal point; +/-7.9228162514264337593543950335 - with 28 places to the right of the decimal; smallest non-zero number is +/-0.0000000000000000000000000001 - User-defined (using Type) Number required by elements The range of each element is the same as the range of its data type. Note: At this time the Decimal data type can only be used within a Variant, that is, you cannot declare a variable to be of type Decimal. You can, however, create a Variant whose subtype is Decimal using the CDec function. I would just use Double if I was you if you want to use numbers longer than 2,147,483,647. Sure, if you don't care about precision. 12-digit numbers might be OK, but if you're multiplying and dividing them a lot, you're going to get inaccurate results. If you're doing integer maths, there's really no excuse not to use an integer datatype. Why would you choose Decimal over Currency, if it means you'll incur the variant overhead? Craig wants to store 12-digit integers, not 20-digit integers. 12-digit integers fit comfortably within the limits of Currency. Currency is an inbuilt data type. "Decimal" is actually a COM data type that is supported in VB6 through using variants. It's not a "native" data type, but if you need really big numbers, or really small numbers with no rounding errors, then you need to use decimals (or, preferably, a different language altogether). Since OP only needs to store large integers I would use Singles, since they are faster and smaller than Currency or Double. I doubt he's going to see too many files that are larger than 1.0E38 bytes. Since OP only needs to store large integers I would use Singles, since they are faster and smaller than Currency or Double. I doubt he's going to see too many files that are larger than 1.0E38 bytes. Hi Woodle. Looking at this page ( theopensourcery.com/vb03tut.htm ) it reads: "Double is much more accurate and even runs about 10-20% faster than Single." Is this true, is it really 10-20% faster using Double than Single? How do I determine how many numeric digits a Double can store if it's maximum is "1.79769313486232E308". I don't understand this number, why does it have an E in it? How do I determine how many numeric digits a Double can store if it's maximum is "1.79769313486232E308". I don't understand this number, why does it have an E in it? That is computerese for 1.79769313486232 x 10 308 . For the origin of this number, have a read of the IEEE 754 standard. As to "how many numeric digits" this is... well, that's an interesting question. Computers generally use "floating-point" arithmetic to represent non-integers, and floating-point numbers have a "precision". This determines how many digits are significant in the number. According to the IEEE 754 spec, double-precision numbers (the Double type in VB) have a precision of 53 bits, which is approximately 15 digits. So in that sense, a Double can only store up to 15 digits. Put simply, the double-precision numbers: 1234567890123456711111 and 1234567890123456799999 are "exactly the same", as far as the computer is concerned -- there is only enough precision to represent the left-most 15 digits accurately.