benchmark: add Windows compatibility

[yaacovCR]

1. use local git clone instead of git archive | tar
2. normalize module path within sampleCode

Motivation: Windows users should not be required to use WSL to run benchmark (or any other scripts). The library should be cross-platform as possible both at runtime and in development.

Furthermore: it may be valuable to benchmark in multiple environemnts, including unix-type environments, WSL, and native Windows runtimes.

[netlify]

✅ Deploy Preview for compassionate-pike-271cb3 ready!

Name	Link
🔨 Latest commit	f75cc49
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/62a0767bb225fc0009d26a3d
😎 Deploy Preview	https://deploy-preview-3628--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[github-actions]

Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋

Supported commands

Please post this commands in separate comments and only one per comment:

• @github-actions run-benchmark - Run benchmark comparing base and merge commits for this PR
• @github-actions publish-pr-on-npm - Build package from this PR and publish it on NPM

[IvanGoncharov]

2. spawn from projectPath to avoid need to handle drive letter

@yaacovCR I don't understand this one, probably because I'm not using Windows for development.
Can you please explain?

Motivation: Windows users should not be required to use WSL to run benchmark (or any other scripts). The library should be cross-platform as possible both at runtime and in development.

Furthermore: it may be valuable to benchmark in multiple environemnts, including unix-type environments, WSL, and native Windows runtimes.

Don't have actual stats but I expect 99% of users use some variant of Linux in production.
That said I agree that it should be comfortable for people to contribute.
I assumed WSL is a good solution for Windows developers but if you feel strongly that we should support native Windows workflow I'm ok to merge it.

[yaacovCR]

3. spawn from projectPath to avoid need to handle drive letter

@yaacovCR I don't understand this one, probably because I'm not using Windows for development. Can you please explain?

Windows paths have colons in them, which node interprets as a protocol like “node:” or “file:” i don’t see the value in introducing the correct presumably file: prefix to the import that would handle this when we have the option to run from working directory and use a relative path. If there is an advantage to using an absolute path, I could reconsider.

Don't have actual stats but I expect 99% of users use some variant of Linux in production.

Unless they are running in browser.

I assumed WSL is a good solution for Windows developers but if you feel strongly that we should support native Windows workflow I'm ok to merge it.

I feel strongly.

[github-actions]

@github-actions run-benchmark

@yaacovCR Something went wrong, please check log.

[yaacovCR]

Windows paths have colons in them, which node interprets as a protocol like “node:” or “file:” i don’t see the value in introducing the correct presumably file: prefix to the import that would handle this when we have the option to run from working directory and use a relative path. If there is an advantage to using an absolute path, I could reconsider.

Fixed with url.pathToFileURL

edited list above

[yaacovCR]

@github-actions run-benchmark

@yaacovCR Something went wrong, please check log.

I cancelled the job after > 1 hour. From the log, this seems to be from the involuntary context switches, related to #3625

I think we need a different solution to this problem. Ideas:

1. We discussed (offline) about whether the Foundation could pay for a dedicated benchmarking machine. Any progress on that?
2. Would os.setPriority help? I imagine that it wouldn't, but maybe it couldn't hurt?
3. What about interleaving the benchmark tests and taking the mean of ratios rather that simple the ratio of the means? If there is something the processor is doing during some portion of the tests, we want that to balance out, and the ratios could still be meaningful.
4. Otherwise, I think after 5 attempts, when running on CI, we should just accept the runs with involuntary context switches, and the benchmark should be updated if possible to take into account only actual CPU time rather than total time. When running locally, it's totally valid for the benchmark to encourage you to close other processes on your machine, but because it's impossible with our current setup, and benchmarks are taking too long to be useful, we should do something different.

Changed as requested

[yaacovCR]

@IvanGoncharov

FYI When trying on WSL, I receive the following error:

Assuming you meant: benchmark --revs local HEAD
🍳 Preparing local...
Error: EXDEV: cross-device link not permitted, rename '/mnt/c/Users/Yaacov/Documents/GitHub/graphql-js/graphql-17.0.0-alpha.1.tgz' -> '/tmp/graphql-js-benchmark/graphql-local.tgz'

Meaning the script as is (and even after this PR) does not support WSL.