From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64243 invoked by alias); 9 Jun 2015 16:54:47 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 64231 invoked by uid 89); 9 Jun 2015 16:54:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: mail-in-08.arcor-online.net Received: from mail-in-08.arcor-online.net (HELO mail-in-08.arcor-online.net) (151.189.21.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 09 Jun 2015 16:54:43 +0000 Received: from mail-in-18-z2.arcor-online.net (mail-in-18-z2.arcor-online.net [151.189.8.35]) by mx.arcor.de (Postfix) with ESMTP id 3m5cxW40VVzBk1L for ; Tue, 9 Jun 2015 18:54:39 +0200 (CEST) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-18-z2.arcor-online.net (Postfix) with ESMTP id 8534C33F109 for ; Tue, 9 Jun 2015 18:54:39 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-06.arcor-online.net 3m5cxW34Xnz8Flf Received: from Gertrud (p4FF1DB71.dip0.t-ipconnect.de [79.241.219.113]) (Authenticated sender: stromeko@arcor.de) by mail-in-06.arcor-online.net (Postfix) with ESMTPSA id 3m5cxW34Xnz8Flf for ; Tue, 9 Jun 2015 18:54:39 +0200 (CEST) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: setup References: <87382fdvjp.fsf@Rainer.invalid> <87h9qkbllg.fsf@Rainer.invalid> <87ioazclrp.fsf@Rainer.invalid> <20150608132823.GN3416@calimero.vinschen.de> <87oakqnkfi.fsf@Rainer.invalid> <20150608193154.GU3416@calimero.vinschen.de> <878ubtor9g.fsf@Rainer.invalid> <20150609095604.GA4993@calimero.vinschen.de> Date: Tue, 09 Jun 2015 16:54:00 -0000 In-Reply-To: <20150609095604.GA4993@calimero.vinschen.de> (Corinna Vinschen's message of "Tue, 9 Jun 2015 11:56:04 +0200") Message-ID: <874mmghlf8.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2015-06/txt/msg00077.txt.bz2 Corinna Vinschen writes: > Right, in the networking case the download should be the major factor, > but I was referring to the SSD case. >> > Can you speed up reading the ini file noticably by defining >> > YY_READ_BUF_SIZE to 65536 in inilex.ll? If so, is the impact of using >> > base64 still an issue, performance-wise? >> >> That's not the right place to do the override, since it ends up after >> the default definition. > > Huh? Not for me: I had been trying to put it before the includes and that buggered up things. Ain't that wonderful? >> In any case, from the Flex manual it doesn't >> make sense to increase that buffer ("it's almost always too large") and >> it is being fed from an io_stream, which is buffered itself. > > Yes, but it's using the default buffersize of the underlying MSVCRT > stdio, which is using some value I don't know off the top of my head. > Typically this would be 1K or 4K. YY_INPUT is reading in 8K chunks, so > the underlying stdio is very likely already skipping its buffering. > So changing YY_READ_BUF_SIZE to 64K *should* have an impact. It still looks that the loading of the file is the culprit and not the parsing, but it's hard to make out the difference on that system here. In any case, setup now manages to write to SSD with about 15MiB/s on average and about 40MiB/s tops (using the gcc-debuginfo package since that has a good mixture of a few very large files and many small files). I'd think that task manager should also show some reading activity (the repo is on the same disk) sinc the compression ration is about 5:1 on avaerage, but nothing. The read activity may generally be too bursty for the performance counters to notice. Making the xz buffers a lot larger (1MiB) didn't change both numbers too much, but unpacking the small files became more "chunky". That may have a benefit with either a beefier CPU (the build system is using a 1037U Sandy Bridge Celeron) or threading setup so that it uses the two cores available (the second core is ATM only utilized by the system, so the load is about 70% on average). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs