new Composite().dispose() is slow on Mac OS

[basilevs]

Creation and disposal of a Composite on Mac OS are very slow

To Reproduce
Run

eclipse.platform.swt/tests/org.eclipse.swt.tests/JUnit Tests/org/eclipse/swt/tests/junit/performance/Test_situational.java

Lines 72 to 105 in 02c8a22

	public void test_createComposites() {
	PerformanceMeter meter = createMeter("Create composites");
	int samples;
	Performance.getDefault();
	// Warm up.
	for(samples = 0; samples < 2; samples++) {
	Shell shell = new Shell(display);
	for (int i = 0; i < 100; i++) {
	Composite c = new Composite(shell, SWT.NONE);
	for (int j = 0; j < 10; j++) {
	new Composite(c, SWT.NONE);
	}
	}
	shell.dispose();
	while(display.readAndDispatch()){/*empty*/}
	}
	for(samples = 0; samples < 100; samples++) {
	Shell shell = new Shell(display);
	meter.start();
	for (int i = 0; i < 100; i++) {
	Composite c = new Composite(shell, SWT.NONE);
	for (int j = 0; j < 50; j++) {
	new Composite(c, SWT.NONE);
	}
	}
	meter.stop();
	shell.dispose();
	while(display.readAndDispatch()){/*empty*/}
	}
	disposeMeter(meter);
	}

It takes 28 minutes to execute on Mac OS

Expected behavior

The test should complete in seconds, like on Linux and Windows.

Screenshots

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

2. Additional OS info (e.g. OS version, Linux Desktop, etc)
   Reproducible in CI
   Reproducible on MacOS Monterey

3. JRE/JDK version
   17

Version since
The test performance meter was implemented incorrectly - it failed to measure deferred events.
Performance tests were never run on CI and performance assertions were disabled three years ago.
eclipse-platform/eclipse.platform.releng@071af51#diff-55cfefb6d6ca7ae136d8057fc7ea93d8b62af5db44fc77cec0f961fc68d2bdbdL85
So the exact date of regression is unclear.

Workaround (or) Additional context
Don't create composites on MacOS.

[basilevs]

History of performance tests by @akurtakov : #906 (comment)

[akurtakov]

For the record - Perf tests results (at least as far as I'm aware) have only be produced by the project on Linux. I was never involved nor remember anything about anyone using these perf tests on Win/Mac in the open.

[basilevs]

I'd like to prevent regressions like this from happening again. The first step that comes to mind - instead of tracking perf data externally, add a sensible assertion in the test code.

However, I'm not sure what is sensible. Is 250 ms per Composite normal on MacOS?

[akurtakov]

Unfortunately, I have found any timing in VMs to be totally unreliable. Sometimes VMs just "sleep" for extended periods and next time they "wakeup" the wallclock is already above any threshold even though the VM was not active and thus did nothing.

[iloveeclipse]

Exact, we see same in our internal tests in VM's. Any time/performance results totally unreliable

[basilevs]

Here, the test takes 28 minutes, how unreliable should VM be to skip half an hour?

[iloveeclipse]

Depends on how host is configured and how many other instances use same hardware.I saw pauses of ~15 minutes , where the VM itself was not doing anything.

[akurtakov]

Here, the test takes 28 minutes, how unreliable should VM be to skip half an hour?

If it's github runner - it might have been affected by the degraded GHA right now https://www.githubstatus.com/

[basilevs]

The test was done on physical Mac Book Pro produced in 2021 and still took 28 minutes. VM slowdowns do not justify/explain the performance.