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: Mon, 08 Jun 2015 22:54:19 +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>
Corinna Vinschen writes:
> I'm certainly not de-valuing your patch, but that makes me suspicious.
> The impact of reading from a local SSD should be rather low. That
> reminds me of the buffer size problem slowing down SHA512 evaluation,
> see git diff 0c7564..8648b05.
> greping setup sources, it seems setup is using smaller buffers in more
> places, e.g.
> compress_bz::read uses 4K buffer
> compress_gz::read 16K
Not using any of these anymore.
> io_stream::copy 16K
I've already enlarged that to 64kiB, but I couldn't really tell the
> YY_INPUT 8K
> Especially YY_READ_BUF_SIZE defined as 8K might be a culprit here.
At least from the network the slow part is the loading of the file
(while the progress bar updates). Parsing should happen in that split
second when the loading is complete and before it switches to the
> 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. 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.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ: