How to programmatically determine the total number of descriptors (variables) available and used? (AREV Specific)
At 29 MAR 2000 05:21:28PM Dean Pollack wrote:
I am trying to trace down a bug that seems to be related to the number of variables used, and it would be very helpful if I could determine this information programmatically. I would like to periodically write statistics to a log, so that when a crash occurs I can determine if it really was due to running out of variables or some other reason.
There must be some way to get this information programmatically. The "Who" window does it. The debugger's "#" command does it. How can I write a program that does it?
Any advice would be greatly appreciated.
At 30 MAR 2000 06:22AM Steve Smith wrote:
The number of descriptors certainly isn't available from the RTP5 RBASIC compiler (that I know). I once tried to find the memory
locations for the variable, but with no joy.
I do know that the descriptor table is a series of 10-byte records starting in RAM at address 8F3F:0000, and each descriptor will hold values below 10 bytes, or point to string space where larger values
are kept. In addition, the descriptor table holds pointers to parent-child called routines. Each item in a matrix (curved brackets) occupies one descriptor. Each dynamic array (angle brackets) only occupies one descriptor. So is less memory hungry than ()
Programs are stored in string space too. Expanded memory is also available for additional string space, but set Windows shortcuts to allow no more than 4096 kB
This would suggest the following tactics would save RAM:
- Run expendable subroutines and functions, especially reports
- Use symbolics that do not reference
dictionary items by using {} squiggly brackets
- compile without linemarks
- use dynamic arrays wherever possible
- avoid hogging the program stack with many small routines where one large one will do.
- remove any unused code.
- externalize error messages in programs (ie. have one error routine and pass it the key to the errors file and read the message from there)
- perform flush and garbagecollect at the start of each routine.
- avoid excessive use of labelled commons
- avoid circular or recursive program structures.
Steve