From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 180B3386103A for ; Sun, 24 Jan 2021 21:59:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 180B3386103A Received: by mail-pg1-x530.google.com with SMTP id z21so7647095pgj.4 for ; Sun, 24 Jan 2021 13:59:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=nrD1OdOW4kxI4BxG40aCzv2/RNJ4NsLtTXjr1wiJp2E=; b=DGmqG4iTLgQcly4exslR3xstqqHElk5qq49fFNKUpJERQ0FsqqKjmln5XsfVCvOSph hIEmi+SH+yyIXvD1GK++awsMPDe6h4laKwsybdlMz88Aun1s1O1dCBhlkrYXyOpc799o gn3PQiBm/J1aLZ+WGOCV6ptFD7P0D8WgXiWejFOKHAkwetXGlJEO54C6oR6e2v//WvO5 zFNfrhV7VgZsvAcCUn7hSsDCag8zXE0JiBMyu6Z4Jr+ZkDUwveMhJtCjgDKr9tPSuhOZ 8BtV4I6x4YyorbHeGDrChTzrmgdbiS6pR9WK17N1Zg9Sq9aXR1U4KddPT6FEwJsxTWaK OCbg== X-Gm-Message-State: AOAM532eQM5h/vjR7GKAsCZgj8rOPPiLEtUSjN8BZy9QlMokc/bJlXwF EiAfoDbXoM/NW2pA5fyOo9lrmpdSEiw4Kw== X-Google-Smtp-Source: ABdhPJx2G/TSeU17OHZqRCNkkB5ZljQ5rY80ioXaVj/IhjSkfR/swHilPqJNKaq590MCTVAq7xeIMg== X-Received: by 2002:a65:6409:: with SMTP id a9mr15157318pgv.212.1611525555275; Sun, 24 Jan 2021 13:59:15 -0800 (PST) Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:99c2:4ab0:3660:4cfc]) by smtp.gmail.com with ESMTPSA id t206sm14313580pgb.84.2021.01.24.13.59.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Jan 2021 13:59:14 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id EE3AE47D8D; Mon, 25 Jan 2021 08:29:09 +1030 (ACDT) Date: Mon, 25 Jan 2021 08:29:09 +1030 From: Alan Modra To: Douglas B Rupp Cc: Binutils Subject: Re: ld using 2 byte writes Message-ID: <20210124215909.GO26219@bubble.grove.modra.org> References: <080185be-4462-e615-97a0-9684a11d55da@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <080185be-4462-e615-97a0-9684a11d55da@adacore.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2021 21:59:17 -0000 On Fri, Jan 22, 2021 at 10:13:05AM -0800, Douglas B Rupp wrote: > > Greetings, > > We have a customer complaint regarding performance with a networked disk on > a windows host, when creating a .dll. > > The complaint is a local link takes 60 seconds, where as a networked link > takes 400 seconds.   Drive characteristics are similar and the network > itself is "very fast". > > Using ProcessMonitor the customer found ld is using a lot of WriteFile calls > with 2 bytes, the biggest was around 200 bytes. > > Curious if this would be a worthwhile project, e.g. an option to write in X > MB chunks?   Possible also for .o files as well as for ld. It would be worth checking to see whether we do something silly in ld to adversely affect IO performance, but otherwise no. Why should ld implement file IO buffering when that should already be happening? -- Alan Modra Australia Development Lab, IBM