Mail Archives: djgpp/1998/06/26/09:13:25
[EMailed reply bounced due to Netiquette-violating address spoofing ...]
In article <35929FCF DOT 9EC9820 AT hal DOT io DOT com> you wrote:
[...]
> The program usually processes relatively large pieces of data, and on
> startup it has to do some memory management.
Please be more specific. What does 'some memory management' mean, exactly?
Most importantly: how much memory are we talking about, and how do you
manage it?
> I tried to profile it, as
> described in the FAQ. And yes, the program spends 70% of its time in a
> function called dpmi_int.
That translates into: it spends those 70% doing *OS* calls ('system
time' in Unix parlance, as opposed to user time). It might be more
interesting to look where the majority of those calls to dpmi_int come
from, and also where the remaining 30% are predominantly spent. After
all, even 70% being spent in the OS would only account for a factor of
3 slowdown caused by this, but never the factor of 200 or so (2
minutes compared to half a second) that you observe.
If you can't get some clues out it yourself, you could email me the
output of 'gprof -b yourprog.exe'. Maybe I can spot something.
> I played around with the dpmi-configuration
> also: More swap space, less swap space... Swap file on ram disk..
> whatever, the lag remains. The Machine I use is a Pentium 100, 32MB RAM;
> dpmi has about 12MB RAM and 128MB swap space at its disposal.
What OS is it? Plain DOS, or a Winblows DOS box?
Anyway: on a 32MB RAM machine, DPMI should always have more than those
12 MB of 'physical' memory available. Where did you spend the other
20? In that specific case, I think you should try a configuration with
NO ramdisk and a maximum of 4 MB given to smartdrv. That should leave
about 26 MB or so to the DJGPP program.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -