public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Cygwin fork performance followup
@ 2021-02-04 14:29 Hamish McIntyre-Bhatty
  2021-02-04 14:44 ` Eliot Moss
  0 siblings, 1 reply; 2+ messages in thread
From: Hamish McIntyre-Bhatty @ 2021-02-04 14:29 UTC (permalink / raw)
  To: Cygwin General Mailing List


[-- Attachment #1.1.1: Type: text/plain, Size: 558 bytes --]

Hi all,

I managed to improve my Cygwin VM's performance significantly using a
variety of methods.

If anyone else is experiencing troubles, seeing what I changed at
https://www.hamishmb.com/blog/improving-cygwins-performance-fork/ might
also help you. Not using VirtualBox was the main improvement for me (now
using KVM/QEMU). Note that I didn't achieve much difference, but that
was because my system is relatively powerful. What isn't shown is that
these changes do seem to help with the fork speed drop-off that occurs
over time.

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Cygwin fork performance followup
  2021-02-04 14:29 Cygwin fork performance followup Hamish McIntyre-Bhatty
@ 2021-02-04 14:44 ` Eliot Moss
  0 siblings, 0 replies; 2+ messages in thread
From: Eliot Moss @ 2021-02-04 14:44 UTC (permalink / raw)
  To: Hamish McIntyre-Bhatty, Cygwin General Mailing List

On 2/4/2021 9:29 AM, Hamish McIntyre-Bhatty via Cygwin wrote:
 > Hi all,
 >
 > I managed to improve my Cygwin VM's performance significantly using a
 > variety of methods.
 >
 > If anyone else is experiencing troubles, seeing what I changed at
 > https://www.hamishmb.com/blog/improving-cygwins-performance-fork/ might
 > also help you. Not using VirtualBox was the main improvement for me (now
 > using KVM/QEMU). Note that I didn't achieve much difference, but that
 > was because my system is relatively powerful. What isn't shown is that
 > these changes do seem to help with the fork speed drop-off that occurs
 > over time.

Yes, fork can be a bottleneck in Cygwin.  I do wonder if we might get some
improvement for a lot of common cases if spawn were used more, in favor of
fork, and Cygwin supported "fast paths" for the simpler cases of spawn, to
where the libraries in the child process would not need to be loaded in the
same place.  More complex cases of spawn could fall back to a fork-based
approach underneath.  The idea is to grab some low hanging fruit - if there is
any.  What I don't know is whether such fruit can be had.  For example, does
bash use spawn, and if so, does it use calls that could be optimized in this
way?  I don't know.  Likewise other tools that do lost of forking might need
to be inspected, such as 'make'.

I seem to recall this was discussed some before ...

Best wishes - Eliot

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-02-04 14:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-04 14:29 Cygwin fork performance followup Hamish McIntyre-Bhatty
2021-02-04 14:44 ` Eliot Moss

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).