This is the mail archive of the
mailing list for the Cygwin project.
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 09 Jun 2015 18:54:35 +0200
- Subject: Re: setup
- Authentication-results: sourceware.org; auth=none
- References: <87382fdvjp dot fsf at Rainer dot invalid> <87h9qkbllg dot fsf at Rainer dot invalid> <87ioazclrp dot fsf at Rainer dot invalid> <20150608132823 dot GN3416 at calimero dot vinschen dot de> <87oakqnkfi dot fsf at Rainer dot invalid> <20150608193154 dot GU3416 at calimero dot vinschen dot de> <878ubtor9g dot fsf at Rainer dot invalid> <20150609095604 dot GA4993 at calimero dot vinschen dot de>
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
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation: