Byte Vs boolean

Oorang

Well-known Member
Joined
Mar 4, 2005
Messages
2,071
I have noticed that boolean is not strictly enforced in VBA. And that the byte datatype is takes half the memory. I have run some tests and have noticed that you can a booean true into byte and get 255 and boolean false and get 0. I have also noticed that if you evaluate byte like it's boolean it will be read false if it 0 and true if it is any other number. Given that the data types seem to be fully interchangable... why would you even want to use boolean? Is there any downside to just using byte in all cases?

Code:
Boolean Data Type 

Boolean variables are stored as 16-bit (2-byte) numbers, but they can only be True or False. Boolean variables display as either True or False (when Print is used) or #TRUE# or #FALSE# (when Write # is used). Use the keywords True and False to assign one of the two states to Boolean variables.
When other numeric types are converted to Boolean values, 0 becomes False and all other values become True. When Boolean values are converted to other data types, False becomes 0 and True becomes -1.

Byte Data Type
Byte variables are stored as single, unsigned, 8-bit (1-byte) numbers ranging in value from 0–255.
The Byte data type is useful for containing binary data.
 

Excel Facts

Copy a format multiple times
Select a formatted range. Double-click the Format Painter (left side of Home tab). You can paste formatting multiple times. Esc to stop
Use the correct data type for the task at hand. If you want a true/false value use a boolean and not something else that can be made to behave like a boolean.

Improving computer performance is fool's gold. How many mega -- or *giga* -- bytes of memory does a typical PC have? My laptop has 1GB, my 4 year old desktop has 2GB.

On a related note...there are many who work themselves into a frenzy saving one function call or 3.14159 CPU cycles or some other equally irrelevant performance metric. What an incredible waste of resources. If the performance of a system depends on saving 1/e CPU cycles, the system designers have a far more serious problem on their hands than hardware optimization.

Hardware costs are a fraction of those of labor. Do things the right way, make life easy for others working on your software -- includng yourself when you look at some piece of code a year or two down the road -- and the *real* savings in labor costs will more than outweigh any *perceived* saving in hardware costs.

I have noticed that boolean is not strictly enforced in VBA. And that the byte datatype is takes half the memory. I have run some tests and have noticed that you can a booean true into byte and get 255 and boolean false and get 0. I have also noticed that if you evaluate byte like it's boolean it will be read false if it 0 and true if it is any other number. Given that the data types seem to be fully interchangable... why would you even want to use boolean? Is there any downside to just using byte in all cases?

Code:
Boolean Data Type 

Boolean variables are stored as 16-bit (2-byte) numbers, but they can only be True or False. Boolean variables display as either True or False (when Print is used) or #TRUE# or #FALSE# (when Write # is used). Use the keywords True and False to assign one of the two states to Boolean variables.
When other numeric types are converted to Boolean values, 0 becomes False and all other values become True. When Boolean values are converted to other data types, False becomes 0 and True becomes -1.

Byte Data Type
Byte variables are stored as single, unsigned, 8-bit (1-byte) numbers ranging in value from 0–255.
The Byte data type is useful for containing binary data.
 
Upvote 0
I actually agree for the most part, but I was thinking in terms of custom database functions that might be repeated 10s of thousands of times in a query. Wouldn't there be some performance benefit there?
 
Upvote 0
Two points.

First, don't do anything unless you have conclusive evidence that a bottleneck exists and then solid evidence of where and what the bottleneck is.

Second, There is often a tradeoff between space and (CPU) speed. *Usually* using a data item that is aligned with the hardware's physical "word" is fastest in terms of speed.

But, that hardware word may be larger than what is ideally needed for a particular data type. You have to decide -- based on hard evidence and not intuition or some "rule of thumb" or some other subjective basis -- what kind of compromise, if any, is required.

Finally, a solution that you design for one platform as "optimal" may turn out to be sub-optimal on another. A simple case would be using a Long on a 32bit machine because it is "optimal." But, on a 64bit machine, the same data type would be "sub optimal." Or even porting a program that includes "Long" from VB(A) to the .Net world would change the performance characteristic!

Personally, I have been responsible for the optimal performance of a few *large* production systems in my career. In each case, I tweaked only the minimum code needed to improve performance, leaving the remaining 90%+ of the system "hardware-inefficient" and "maintenance-efficient". Actually, in several of those systems, after getting improvements of several % points, I demonstrated that using a more appropriate algorithm would improve performance by a magnitude.

So, bottom line...be real sure that (a) there is a need for optimzation, (b) verifiably determine where and how which small parts of the system will yield the necessary improvement. But, most of all, invest the time to figure out if (c) a better solution exists based on a different way of approaching the problem.

I actually agree for the most part, but I was thinking in terms of custom database functions that might be repeated 10s of thousands of times in a query. Wouldn't there be some performance benefit there?
 
Upvote 0

Forum statistics

Threads
1,213,504
Messages
6,114,020
Members
448,543
Latest member
MartinLarkin

We've detected that you are using an adblocker.

We have a great community of people providing Excel help here, but the hosting costs are enormous. You can help keep this site running by allowing ads on MrExcel.com.
Allow Ads at MrExcel

Which adblocker are you using?

Disable AdBlock

Follow these easy steps to disable AdBlock

1)Click on the icon in the browser’s toolbar.
2)Click on the icon in the browser’s toolbar.
2)Click on the "Pause on this site" option.
Go back

Disable AdBlock Plus

Follow these easy steps to disable AdBlock Plus

1)Click on the icon in the browser’s toolbar.
2)Click on the toggle to disable it for "mrexcel.com".
Go back

Disable uBlock Origin

Follow these easy steps to disable uBlock Origin

1)Click on the icon in the browser’s toolbar.
2)Click on the "Power" button.
3)Click on the "Refresh" button.
Go back

Disable uBlock

Follow these easy steps to disable uBlock

1)Click on the icon in the browser’s toolbar.
2)Click on the "Power" button.
3)Click on the "Refresh" button.
Go back
Back
Top