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 <dpchr...@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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
