Mail Archives: djgpp-workers/2001/08/20/02:55:18
On Sun, 19 Aug 2001, Charles Sandmann wrote:
> > I'm nervous about calling malloc at that stage.
>
> I put it on the stack in this new version. Turns out to be smaller,
> simpler (better) code anyway.
>
> > Also, maybe the comments in the code could be made more explicit about
> > things that are done by each of the options, to avoid maintenance
> > problems in the future.
>
> Added 3 big blocks of comments and additional line comments.
>
> There are some other optimizations using the LAR code which can be
> added into the option 2 (NT) section to make it faster which might
> cause us to increase the how_deep parameter. Andris' code scaned
> 8192 - this only scans 12 (which may be too few by default). But
> I would like feedback before futzing with it more.
Perhaps it would be usefull to increase the default. For example
if gcc runs: cpp1.exe, cc1.exe, as.exe, collect2.exe and ld.exe and is not
linked with libc.a where this feature is included we already have more.
If we're compiling more sources when invoking gcc things are even worse.
So I suggest to increase the default to something like 50
Other suggestion:
move 'char desc_map[how_deep]' inside
if (workaround_descriptor_leaks)
block. In this case we can set initial value depending on
workaround type. If we can use LAR then I think it's safe
(and fast enough) to scan at least 100 descriptors. I think
it's better while most DJGPP packages are not rebuilt with
new libc. Scanning 8192 descriptors took about 30% overhead
when spawned program simply quits. I think even 3% would be
acceptable as it would not noticeable in most real life
situations. Initial value of limit could be reduced in
future when most packages will be built using new libc.a
Andris
- Raw text -