www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/03/21/09:56:48

Date: Thu, 21 Mar 1996 16:49:47 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: rbabcock AT cfa DOT harvard DOT edu
Cc: djgpp AT delorie DOT com
Subject: Re: Faster floppy I/O
In-Reply-To: <DoJzLG.CGJ@cfanews.harvard.edu>
Message-Id: <Pine.SUN.3.91.960321163759.25106G-100000@is>
Mime-Version: 1.0

On Wed, 20 Mar 1996, Bob Babcock wrote:

> Does this affect ld.exe?  Linking always seems to take a long time,
> and generates a lot of disk activity (which I don't think is swapping

Maybe.  Unfortunately, no one (AFAIK) have tried to see how does ld 
perform when `fseek' and `ftell' do not discard the buffered portion of 
the file.  I didn't even hear reliable reports that these two functions 
are indeed the cause of slow operation (e.g., profiling ld would be 
nice), or even, for that matter, that ld uses `fseek' heavily.

On the other hand, a few people reported that stubediting ld to enlarge
the transfer buffer to 64K made it *much* faster, so you might try this.  
If you do, maybe you could investigate this a bit further, because people 
who reported this seem to work with networked drives, and I don't know if 
the suggestion is also valid for other kinds of disk.

The reason I'm not sure about the whole issue is that ld works reasonably 
well for me (under native DOS) without any excess disk activity, although 
I didn't really compare its speed with the v1.x version.

- Raw text -


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