Mail Archives: djgpp/2000/10/04/11:00:23
Eli Zaretskii wrote:
> Also, do you need to know the total size of physical memory, or the amount that is
> free at the moment of the call, and for what purpose?
I have encountered two very practical reasons to know the amount of memory on a machine
(not necessarily *physical* memory):
1. To predict how large a region can be successfully malloc'ed. One might well ask
why this can't be done simply by testing for a null pointer returned from malloc.
Unfortunately, this works poorly with some algorithms. For instance, a routine
that creates an array of pointers, each element pointing to the beginning of a
line in a text file, can't predict how much space it needs for the array until it
has counted the number of lines in the file. This means either making two passes
over the file (slow), doing a lot of realloc calls along the way (also slow), or
reserving space at the outset for the largest array one might need (fast and
expedient). (Determining that size by a binary search is not reliable, since
after a malloc-free pair the heap is not necessarily in the same state it was in
before.)
2. To predict how large a region of memory can be accessed without disk swaps. (For
instance, will a particular invokation of qsort be painfully slow, requiring a
call to a special-purpose disk-based sort?)
> The DJGPP library provides the `_go32_dpmi_remaining_physical_memory ' function for
> this purpose. Another possibility is to call the function
> `_go32_dpmi_get_free_memory_information'.
Do these functions accomplish either of the above goals?
-Eric Rudd
rudd AT cyberoptics DOT com
- Raw text -