RAM optimization

[Paul Dixon]

Erich,
you can usefully use your knowledge of how RAM and cache affect code speed by writing your programs with that in mind but I don't think it's something a compiler will ever do well. It's something best left to the programmer.
It's not often that you'll gain a lot anyway. The overhead of the compiler will usually swamp any gains. In the few cases where there is a significant amount to be gained then you'd be better off using ASM.

Paul.

[Michael Mattias]

Frankly I think this stuff is ABSOLUTELY NOT part of any high-level language such as BASIC. To avoid thinking about this is why you licensed a high-level language compiler in the first place.

Besides, you already can set your program's working set size (keep stuff in memory); set the priority of any thread owned by your program; and follow the performance suggestions in the help file (eg, use LONG datatytypes and zero-based arrays).

Not to mention, if you already code like a doofus, this kind of thing is not going to help.

MCM

[Erich Schulman]

I have been reading a big article about memory at http://lwn.net/Articles/250967/
After reading Part 5, it seems PB could benefit from the option to give the compiler hints about your code.

It should not be too hard to integrate into PB's syntax. A few examples of what it could look like.

IF EXPECT c%>127, EXPECT d%=55, c%<127 AND D% = 55 THEN DoSomething

IF EXPECT TRUE, NOT ErrorFlag THEN DoSomething

SUB DoSomething() HINT whatever ' hints about when and how often the SUB/FUNCTION is used
LOCAL MyCounter AS BYTE, MyName AS STRING
...
END SUB

DIM A(2530) AS DOUBLE NONTEMPORAL ' don't let this array go into cache, perhaps it is rarely needed

Any interest?