Memory and Optimization...

[Max_aka_NOBODY]

I've searched the forums high and low about the different approaches on optimization, memory management, and speed, but whenever I find something interesting, either the next poster or a simple test proves it wrong, so I have a couple of questions, mostly basics, that I'd really like to know:

1-Why is boolean 16-bit? Isn't it supposed to hold 1 bit of data, either 1 or 0? Why not switch all booleans with bytes then?

2-Is there any difference in the performance of IF-blocks and SelectCase-blocks?

3-Could someone please explain in-depth what the 'Advanced Optimizations' do? Ok, I understand that "Remove Array Bound Checks" removes arrays boundaries, but what does aliasing mean? It isn't visual aliasing, is it? Or what are "FDIV" checks?

4-From my tests, it seems that each time an array(I tested mostly with UDT arrays) is redimensioned with only one element(0), some parts of it are left in memory, which clogs it quite a lot over time. Is there a way around this?

5-In binary reading mode, skipping data with Seek doesn't seem to give different performance from Getting the data. Is that correct?

6-Using a benchmarking module by one of the forum members(sorry, can't remember the UN), I found that simple mathematical operations on integers\longs are performed faster than on bytes. Is the module flawed, or is it supposed to happen?

7-Getting the data by small chunks seem to be around 10x slower than reading it once. Why would that happen?

Thanx in advance!

[bpd]

1-Why is boolean 16-bit? Isn't it supposed to hold 1 bit of data, either 1 or 0? Why not switch all booleans with bytes then?

Booleans are 32-bit. The reason is that on 32-bit processors, the "natural" size of a word is 32-bits. So dealing with this size number is faster. This also answers your question #6.

2-Is there any difference in the performance of IF-blocks and SelectCase-blocks?

The subject of the Select Case is evaluated once and compared many times. With a blocked IF, the subject is evaluated & compared many times. So, yes, there is a performance difference.

3-Could someone please explain in-depth what the 'Advanced Optimizations' do? Ok, I understand that "Remove Array Bound Checks" removes arrays boundaries, but what does aliasing mean? It isn't visual aliasing, is it? Or what are "FDIV" checks?

FDIV refers to a floating point division bug in some older Pentium processors.

Aliasing is when two variables refer to the same memory location. For instance, in the following example, the formal parameter MyParm is an alias for the global variable MyGlobal. Both variables refer to the same memory location:

Private MyGlobal As Long
 
Call MySub(MyGlobal)
 
Private Sub MySub(ByRef MyParm As long)
  'Because MyGlobal was passed ByRef, both MyParm 
  'and MyGlobal refer to the same memory location.
End Sub

On the Advanced Optimizations tab, hit the "Help" button - there are some pretty decent descriptions there.

4-From my tests, it seems that each time an array(I tested mostly with UDT arrays) is redimensioned with only one element(0), some parts of it are left in memory, which clogs it quite a lot over time. Is there a way around this?

Hmmm, I would tend to doubt this happens. How have you determined this to be true?

5-In binary reading mode, skipping data with Seek doesn't seem to give different performance from Getting the data. Is that correct?

Perhaps, over short distances, there may not be a noticable performance difference; however, I suspect that over long distances, Seek would be faster.

6-Using a benchmarking module by one of the forum members(sorry, can't remember the UN), I found that simple mathematical operations on integers\longs are performed faster than on bytes. Is the module flawed, or is it supposed to happen?

(See answer to question #1)

7-Getting the data by small chunks seem to be around 10x slower than reading it once. Why would that happen?

The overhead in each I/O operation makes reading large chunks faster. Also, all memory is read in standard size chunks (I believe it is 8K), regardless of how much you actually ask for.

[szlamany]

To elaborate...

Booleans are 32-bit. The reason is that on 32-bit processors, the "natural" size of a word is 32-bits. So dealing with this size number is faster. This also answers your question #6.

The ASM/Machine code on a 32 bit machine wants to deal with 32-bit memory spaces. The processor/memory is all designed to deal with it this way. Learning ASM will take some of this mystery away.

Accessing a byte in VB still causes the whole 32 bit longword to be addressed.

The subject of the Select Case is evaluated once and compared many times. With a blocked IF, the subject is evaluated & compared many times. So, yes, there is a performance difference.

It would be just as easy in VB to evaluate the condition once and then use the IF statement on that "variable" - making it quite like the SELECT/CASE statement. The SELECT/CASE statement in machine code does a JUMP to the next "code statement" after the SELECT/CASE upon finding a CASE that matches. That can be simulated in VB with a GOTO - which is bad form in 3rd generation languages, but is actually how the SELECT/CASE implements in machine code.

I understand that "Remove Array Bound Checks" removes arrays boundaries

No that's not the case - it simply means that the run-time code won't check array boundaries prior to accessing the array. This means less machine code in the exe - it simply does not check the array spot againt the boundaries.

[Max_aka_NOBODY]

Thanx. That clears up quite a bit... So, it is better then to keep everything as longs than as bytes, right? And on 64-bit processors as doubles\64-bit integers?

4-From my tests, it seems that each time an array(I tested mostly with UDT arrays) is redimensioned with only one element(0), some parts of it are left in memory, which clogs it quite a lot over time. Is there a way around this?

Hmmm, I would tend to doubt this happens. How have you determined this to be true?

By the task manager in XP. My program uses around 150 MBs for UDT arrays when a big file is loaded, and when I clear up everything the memory doesn't go back to the exact value it was before it was loaded, and with each subsequent load, it goes up by 1-3MB...

Also, is it just me or does a common dialogue control take up 1.5MB of RAM? I compiled my prog(with no code) without it, and the memory usage went down by 1.5MB...

[szlamany]

Thanx. That clears up quite a bit... So, it is better then to keep everything as longs than as bytes, right? And on 64-bit processors as doubles\64-bit integers?

Well - general statements like that just aren't possible.

I would personally never use a BYTE or WORD (16-bit) variable in a program - unless required for some reason (like the INDEX parameter of a control-array click event is an INDEX).

But, making an array of 25000 figures that would never exceed a value of 100 - then I might use a BYTE array.

Small-size arrays stink because of signed versus non-signed - the max's are halved.

[Max_aka_NOBODY]

Well, for example my prog reads Long flags as byte + 3 bytes padding(which are skipped) since only the first digit is used. Now does that mean that it's better to read the whole long value?

[szlamany]

I would need to research a bit to see how a 25000 slot array of byte values stores in memory - maybe someone knows that answer. I would hope the storage is not wasted, but is utilized in the array.

My knowledge of mainframe assembler is much stronger than PC...