Dynamic memory allocation stack heaps

[vivek]

Thanks for the replies.

I will take this issue up with the complier people.

 

[James Kuyper]

Digressing from pure C here...

For web application developers using C# or Java, I can accept that. I
used to work with a very senior developer who did not know about
endianess, not to mention stack/heap. What I didn't realize was that a
PC/Server programmer would not concern about such things, thus my
surprise. I forgot to mention that I was interviewing people for a
position that will involve with device driver programming in small
devices such as Window CE and embedded Linux.

Yes, that makes a big difference.

Anyway, in my group's opinion, people understand the memory layout in
general usually produce higher quality programs.

True, but that's more true of implementation-specific code than it is
for code that needs to be more portable.

Also, I don't understand why the multi-megabyte automatic variables
would be a memory hog instead of CPU hog. Your program needs the
amount of memory anyway for doing whatever it does.

Not really; the amount of memory it uses is rather arbitrary. The data
it works with is organized (in order of decreasing size) into 5-minute
granules containing about 203 scans, each of which has 1354 frames, each
of which has 10 pixels. As originally designed, it was intended to
process 24 consecutive granules per run (though we now use it for only
one granule per run). The program is currently written to process an
entire scan of data at one time. It could have, with almost equal ease,
been designed to process only a pixel at a time, or all 24 granules at a
time (if sufficient memory were available), or at any level in between.
Each level of organization carries corresponding memory space/speed
trade offs. To work on the systems I was using at my previous job, it
would have had to run on no more than a frame at a time.

Quite frankly, I don't know if the best choice was made; it was made
many years before I became responsible for the program. I couldn't
possibly justify the major redesign required to test the other
possibilities at this time, not without strong evidence that it would
improve performance; but those other possibilities were feasible at the
time the program was first designed.