Re: Cygwin Perl has slowed in recent months

[Sam Edge <sam.edge@gmx.com>]

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.

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. You can
get older revisions of Cygwin & Perl from the Cygwin Time Machine
(GFGI). 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).

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

If they are so vital to your business, you need to be doing regression
testing yourself before upgrading production systems and maintaining
your own Cygwin repo so you have a copy of the production releases.

This is all SOP for using FOSS in a business context, unless you're
willing to pay someone else to do it for you, which is how Red Hat et al
make their money.

--
Sam Edge