fix(runner): Use performance.now instead of Date.now for duration

[LuciNyan]

Description

Close: #6377

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[netlify]

✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	97432f9
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/66cd997383d3e70008e0aa36
😎 Deploy Preview	https://deploy-preview-6382--vitest-dev.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 configuration.

[LuciNyan]

Hi team! 👋
I'm seeing some flaky tests here. Not sure if we've got some unstable tests on our hands or if there's something else going on. Could you take a look at this 👀

[sheremet-va]

Why?

[sheremet-va]

Why?

[LuciNyan]

Hi! @sheremet-va 👋

Date.now() gives us milliseconds since 1970, but performance.now() doesn't.
The name 'startTime' implies it might be used as a specific timestamp, like in test/cli/test/reported-tasks.test.ts:106.

const diagnostic = passedTest.diagnostic()!
expect(diagnostic).toBeDefined()
expect(diagnostic.heap).toBeGreaterThan(0)
expect(diagnostic.duration).toBeGreaterThan(0)
expect(date(new Date(diagnostic.startTime))).toBe(date(now))
expect(diagnostic.flaky).toBe(false)
expect(diagnostic.repeatCount).toBe(0)
expect(diagnostic.repeatCount).toBe(0)

If we switch to performance.now(), we'll probably need to update that test file. So, do I need to do this?

[sheremet-va]

Yes, I would expect it to use the new now

[LuciNyan]

Thanks for the review! I've made the changes you suggested.

[LuciNyan]

Hey @sheremet-va 👋,

I've noticed something important about our test execution, particularly for files like test/reporters/tests/merge-reports.test.ts. We're using Tinypool from packages/vitest/src/node/pools/forks.ts to spawn new processes for these tests.

The issue is with our use of performance.now(). While it works fine for timing within a single process, it becomes problematic across multiple processes. Each process has its own time reference for performance.now(), starting from when that process begins.

This causes issues when we try to use these startTime values for sorting in packages/vitest/src/node/reporters/blob.ts. The times from different processes aren't comparable.

  const files = blobs
    .flatMap(blob => blob.files)
    .sort((f1, f2) => {
      const time1 = f1.result?.startTime || 0
      const time2 = f2.result?.startTime || 0
      return time1 - time2
    })

Given this, I still think we should use Date.now() for startTime. It provides a consistent timestamp across all processes.

What are your thoughts on this? Do you see any potential drawbacks to switching to Date.now()?

[sheremet-va]

Hm, I see. Let's keep using Date.now then, but we need to store it before it's called because it can be overwritten by the user.

[LuciNyan]

Ready for review! 🚀