Sample program using the new _Files$ function

[dakra137]

So, Steve, I've been using _BYTEs for my boolean TRUE/FALSE flags thinking that they take up less memory than an INTEGER. Is that a FALSE notion?

_BYTES are good.  Bytes are your friend, as they're only 1 byte in size.  (That's as small a chunk of data as you can store on your drive, or in memory.)

INTEGERs are 2 bytes in size, so you'd use twice as many bytes to just hold a simple True or False value.  

The issue is there's folks who somehow think _BIT is better than _BYTE, and it's not.  _BIT only has one use -- and I'd call it a very limited case use scenario -- and that's for bit packing arrays.

DIM Array(800) AS _BIT

The above would pack 800 bits into that array and store them in 100 bytes.  Your program would use less memory and the data would take up less space on disk.

The disadvantage?   It's a lot like compressing files into a zip or 7z archive.  Sure, those files are smaller, but they're useless until you extract them.  To make use of them, you've got to load them, decompress them, then reference them.

And that's basically how bit packing works.  Packing 800 bits of data into 100 bytes, which then has to be extracted, "mathed upon" to get the right bit value from the relevant byte, and then used in your program.

It's a lot of overhead in a program, and for what??  In this case, you'd save 700 bytes of memory/storage?   WOOOOOOOOOOOOOOOOooooooooo....

Without *LARGE* Arrays for bitpacking, there's just not much use for the variable type.  Definitely no use for it when it comes to storing single values, which you then compress/decompress, just to end up storing in a byte anyway.

---

I think integers and bytes are the same size on the backend, if I'm not mistaken.

INTEGERS are 2 bytes.  _BYTE is 1 byte.

Code: (Select All)

Dim b As _Byte

Dim i As Integer

Print Len(b)

Print Len(i)

There are three factors here.

1. Quickest Load/Store at small scale
In QB64, loading or storing a
64 bit long type _INTEGER64 or Double takes the fewest CPU clock cycles on most processors.
1 bit type _BIT takes the most CPU clock cycles on some processors. That is due to extra instructions to calculate, mask and maybe shift to use and the instructions to calculate, load, mask, and save to store the value.

2. Maximum problem size that can be handled
A large array of type _BIT may fit in memory when an array with larger elements would not.

Code: (Select All)

_Define I-N As _INTEGER64

_Define A, C-H, O-Z As DOUBLE  ' 64 bit float

_Define B As _BIT  'Choice of:  _BIT, _BYTE, INTEGER, LONG, _INTEGER64  using  1, 8, 16, 32, or 64 bits



bFalse = 0

bTrue = Not bFalse



ksize = 2000000000

ReDim bitarray(ksize)

3. Cache Hits performance advantage
When the "working set" of executable code and data fit entirely in cache, the program runs quicker.
This may not matter for I/O bound programs, but certainly does for CPU bound programs.
If it all fits in L1 cache, astounding.
If it all fits in L1+L2 cache, wonderful.
If it all fits in L1+L2+L3 cache, excellent.
In my recent application, at all problem sizes above ksize=1000000, _BIT outperformed larger sized array elements.