Re: Cygwin Perl has slowed in recent months

[David Christensen <dpchrist@holgerdanske.com>]

On 5/24/22 08:59, Sam Edge wrote:
> On 24/05/2022 16:03, David Christensen wrote:
>> On 5/24/22 01:47, Sam Edge wrote:
>>> On 24/05/2022 09:25, Csaba Raduly wrote:
>>>  > On Mon, 23 May 2022 at 20:47, Lee  wrote:
>>>  >>
>>>  >> On 5/22/22, David Christensen <dpchrist@holgerdanske.com> wrote:
>>>  >>> On 5/21/22 10:55, Hans-Bernhard Bröker wrote:
>>>  >>>> Am 18.05.2022 um 03:53 schrieb David Christensen:
>>>  >>>>
>>>  >>>>  > I am working on a Perl module that runs on various Unix-like
>>> platforms.
>>>  >>>>  > When I 'make test' on similar computers:
>>>  >>>>  >
>>>  >>>>  > FreeBSD 12.3-RELEASE         28 wallclock secs
>>>  >>>>  > Debian GNU/Linux 11.3          31 wallclock secs
>>>  >>>>  > macOS 11.6.2              36 wallclock secs
>>>  >>>>  > Windows 7 / Cygwin 3.3.5-1    509 wallclock secs
>>>  >>>>
>>>  >>>> Given the complete lack of information about what that Perl
>>> module of
>>>  >>>> yours might be doing, that's hard to have a meaningful discussion
>>> about.
>>>  >>>
>>>  >>>
>>>  >>> Thank you for the response.  I was hoping there was a known issue.
>>>  >>> Apparently, not.
>>>  >>
>>>  >> What I consider a well known issue is that process start up time is
>>>  >> _very_ slow.  If your  'make test' starts lots of processes that
>>> could
>>>  >> be a problem.
>>>  >>
>>>  >
>>>  > While Cygwin''s fork emulation is indeed  slow (I once measured
>>> 1000:1
>>>  > between Cygwin and Linux  * ),
>>>  > "make test" likely started roughly the same number of processes
>>> "then"
>>>  > as it does  "now".
>>>  > In  which case the increase in the run time could be attributed to
>>> Cygwin.
>>>
>>> Indeed.
>>>
>>> But perhaps what the Cygwin core and/or Cygwin Perl maintainers need
>>> is a
>>> simple test case Perl script that can be shown to be much slower on the
>>> current
>>> releases than it was on a named earlier pair of releases. And maybe some
>>> testing by the original poster to see if it is the Cygwin or Perl
>>> release
>>> change that causes the issue.
>>>
>>> Anecdotal observations do not an issue report make. ;-)
>>
>>
>> So, we are discussing running a Perl benchmark for various
>> combinations of Cygwin version and/or Cygwin Perl version.  That is an
>> O(n) and/or O(n**2) problem.
>>
>>
>> If multiple benchmarks are considered, increase the O() exponent by one.
>>
>>
>> If multiple versions of Windows are considered, increase the O()
>> exponent by one.
>>
>>
>> If multiple computers are considered, increase the O() exponent by one.
>>
>>
>> Does the Cygwin project do any of the above?  If so, how?  Where are
>> the test plans and assets?  Where is the raw data?  Where are the
>> reports?
>>
>>
>> If end users are expected to do the above, please advise:
>>
>> 1.  How to install multiple versions of Cygwin on Windows 7
>> Professional 64-bit Service Pack 1 on an x86_64 computer such that
>> each instance of Cygwin does not interact with any other instance of
>> Cygwin.
>>
>> 2.  How to install multiple versions of Cygwin Perl on each of many
>> Cygwin installations on Windows 7 Professional 64-bit Service Pack 1
>> on an x86_64 computer such that each instance of Cygwin Perl does not
>> interact with any other instance of Cygwin Perl or Cygwin.
>>
>> 3.  What is a suitable Perl benchmark?
>>
>>
>> David
>>
> The Cygwin core & Perl maintainers do not get paid for their work.


I do not get paid for working on Cygwin and/or Perl.  But, I have been 
paid for using and programming both.


> If you believe you have spotted a regression, it's up to you to isolate
> at what revision of Perl or of Cygwin core it started to happen. 


If Cygwin provides me with the means; fair enough.


> You can
> get older revisions of Cygwin & Perl from the Cygwin Time Machine
> (GFGI). 


https://html.duckduckgo.com/html?q=site%3Acygwin.org%20cygwin%20time%20machine

https://cygwin.cygwin.narkive.com/cSRkGFjw/time-machine

http://www.fruitbat.org/Cygwin/index.html#cygwincirca

http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html


I built a similar hack years ago.


GFGI Programming Systems Product


> You can have as many parallel installations of Cygwin and its
> packages as you like simply by specifying different install paths when
> running the setup program (RTFM).


Section?  Page?


> Like most FOSS, Cygwin & its packages are provided with no warranty.


https://cygwin.org/faq.html#faq.what.free


> If they are so vital to your business, you need to be doing regression
> testing yourself before upgrading production systems 


Have you been spying on me?  ;-)


> and maintaining
> your own Cygwin repo so you have a copy of the production releases.


https://cygwin.org/faq.html#faq.what.version

https://cygwin.org/faq.html#faq.setup.old-versions


I would say "disappointing", but I think you found the answer (below).


> This is all SOP for using FOSS in a business context, 


TIMTOWTDI.


> unless you're
> willing to pay someone else to do it for you, 
> which is how Red Hat et al
> make their money.


I think you have found the answer.


David