zend_hrtime: Use clock_gettime_nsec_np() for macOS if available

[TimWolla]

This is completely untested, because I do not have macOS available.

---

As per the Apple developer documentation:

Prefer to use the equivalent clock_gettime_nsec_np(CLOCK_UPTIME_RAW) in
nanoseconds.

and also

This API has the potential of being misused to access device signals to try
to identify the device or user, also known as fingerprinting. Regardless of
whether a user gives your app permission to track, fingerprinting is not
allowed. When you use this API in your app or third-party SDK (an SDK not
provided by Apple), declare your usage and the reason for using the API in
your app or third-party SDK’s PrivacyInfo.xcprivacy file.

see https://developer.apple.com/documentation/kernel/1462446-mach_absolute_time

[TimWolla]

checking whether clock_gettime_nsec_np is declared... yes

In the CI output for macOS. So this is probably correct, unless I messed up the checks in the C code.

[devnexen]

It is good, code-wise. I recall clock_gettime_nsec_np has a higher overhead but should be negligible in practice.

[edorian]

checking whether clock_gettime_nsec_np is declared... yes

In the CI output for macOS. So this is probably correct, unless I messed up the checks in the C code.

Compiled on an M3 Pro.

checking whether clock_gettime_nsec_np is declared... yes`

 #elif ZEND_HRTIME_PLATFORM_APPLE_GETTIME_NSEC
        printf("apple_gettime_nsec\n");
        return clock_gettime_nsec_np(CLOCK_UPTIME_RAW);

showed that it's hitting the newly added branch for me.

---

Rough measurements without the printf:

cat hrtime.php

<?php

$a = hrtime(true);
$b = hrtime(true);
echo $b - $a;

while true; do sapi/cli/php hrtime.php && echo; done
9750
750
917
791
875
875
3500
27708
833
1292
1209
1208

[petk]

I have no idea about possible performance issues in this case but I think this is ok, yes. Thanks.

[jorgsowa]

Can you please @TimWolla have a look at my PR? #17437