delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1996/06/23/04:02:05

Date: Sun, 23 Jun 1996 11:00:20 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Oberhumer Markus <k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: linking speedup ?
In-Reply-To: <199606221644.SAA01348@c210.edvz.uni-linz.ac.at>
Message-Id: <Pine.SUN.3.91.960623105347.1039Q-100000@is>
Mime-Version: 1.0

On Sat, 22 Jun 1996, Oberhumer Markus wrote:

> I have noticed that the linking process of bigger programs (e.g. a C++
> program with debug info) is very slow when delayed-write disk cache is
> disabled (as I do because of safety reasons).

If you use SmartDrv and disable delayed-writes with the /X switch, try 
using /N/F instead.  This enables write-through, but flushes the delayed 
writes when a program exits.  IMHO this gives you about the same safety 
without sacrificing too much of a speed.

Did you try stibediting ld.exe to enlarge its transfer buffer to 64KB?  
Some people say they've got a large speedup after they did this.

> After a look at the specs I suspect this is because gcc calls stubify
> after ld created the COFF image. Is this true ?

I doubt it, unless your image is very large indeed.  Stubify is usually
very fast compared to ld.exe.  But you can see how much time each of the 
programs takes by adding -v to the gcc command line and looking at your 
watch when gcc prints the programs it invokes.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019