I need a large array of things that are either true or false
Is it better for speed and space to use booleans with true and false or integers with 1 and 0 or does it really make no difference?
I need a large array of things that are either true or false
Is it better for speed and space to use booleans with true and false or integers with 1 and 0 or does it really make no difference?
What is ālargeā?
If itās really large, you can use a MemoryBlock and set and check the bits. This is maybe faster as an array.
My experience:
I consider the use of an integer to be the backing for a boolean to be wasteful of memory.
You can hold a boolean in one bit, but getting the value in or out is expensive since the underlying memory is still 64bit integer and needs logical AND /OR to get the value
You dont say HOW large an array
Use an array of booleans for speed regardless of memory
If you want to save memory, set up a memoryblock of (n) bytes in size, and store 0 or 1 in those
Access them using mymb.byte(x) in the same way as you would an array
It may be a bit slower than an array of booleans, but you dont say how fast or slow it needs to be.
Oh, and having made some apps that started life as āthis can be true or falseā, I later found cases where a third or 4th condition was useful.
Future proofing for that suggests use an integer type, since you can later extend from
x = 1 or x = 0
to x = (any value up to 255 for example)
The days of bit twiddling are over. A boolean takes up a single byte, 8 bits. Even for an array of 10 million booleans, I wouldnāt try to pack them 8 to a byte. Code clarity trumps memory compression in this case. Keep it simple, use an array of booleans.
Thanks for those opinions. Iām not thinking of arrays in the millions and so far my Macs are coping OK, although my desktop iMac is getting quite elderly and the app Iām working on is growing like Topsy.
Only enough, Jeff, I had just opted for booleans when I suddenly realised there would be occasions when the things Iām using could be both one thing and the other, like quantum particles, I suppose, so I could do with a 2 as well as a 0 and a 1. Maybe Iāll revert to integers while I still can!
I donāt agree. This is about knowing your data. And because I donāt know what Steveās data is for, Iāve asked what large means. Maybe it doesnāt matter for a few thousand array items; if you have to store and reload 10 million values youāre in another situation.
And those booleans, if stored to an SQLite database, take zero bytes each.
Oops, I meant to type āoddly enoughā not āonly enoughā or maybe it was one of those useful input correction features, but I canāt seem to edit it now. Iām not sure who you are disagreeing with, Carsten. I only have a few hundred array elements in mind, big enough for me, not even thousands, which seems to be nearly nothing by modern standards, I just wanted to avoid wasting memory and processor time as a matter of good practice, but I suppose it doesnāt matter any more at these levels. When I first started programming, in machine code on a Sinclair ZX80, I could get a Space Invaders game or a disassembler into fewer than 700 bytes, so just ignore me, Iāll soldier on with my little app.
I disagree with ābit twidfling times are overā w/o knowing what large means.
I disagree with āThe days of bit twiddling are over.ā just because itās not really true. APIs for instance are full of bit fields. But I agree that for an array, an array of booleans may reach an average point in speed/size.
You can do indexed things directly as
Var flag() As Boolean
For i As Integer = 0 to 9999
flag.Add(i mod 11 = 0)
Next
flag(1234) = True
flag(88) = not flag(1234)
If flag(33) Then System.DebugLog "flag 33 is True"