time.clock_gettime_ns() is too slow

[socketpair]

Feature or enhancement

Proposal:

Actually, this is a performance bug. Not a feature/enhancement.
clock_gettime_ns() does not use floating point operations and should be faster than old gettimeofday(). Unfotunately in Python it's not so. Checked in Linux X86_64 kernel 6.5.7, CPython 3.11.6

In [11]: timeit time.clock_gettime_ns(0)  # CLOCK_REALTIME
55.4 ns ± 1.22 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [12]: timeit time.clock_gettime_ns(5) # CLOCK_REALTIME_COARSE
45 ns ± 0.324 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [13]: timeit time.time()
36.7 ns ± 0.953 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-111482: Use Argument Clinic for clock_gettime() #111641
• gh-111482: Fix time_clockid_converter() on AIX #112170

[pochmann]

"too slow" for what?

[socketpair]

@pochmann too slow comparing to time.time() = gettimeofday(). For example, CLOCK_REALTIME_COARSE by definition should be faster (but coarse). In fact, it's not faster in Python. I did a glimpse on the implementation. For reasons that I don't understand, there are many useless wrappers around simple things.

Why not to do this:

static PyObject *
time_clock_gettime_ns(PyObject *self, PyObject *args)
{
    int clk_id;
    if (!PyArg_ParseTuple(args, "i:clock_gettime", &clk_id)) {
        return NULL;
    }

    struct timespec ts;
    if (clock_gettime((clockid_t)clk_id, &ts)) {
        PyErr_SetFromErrno(PyExc_OSError);
        return NULL;
    }

    return PyLong_FromLongLong(ts.tv_sec * 1000000000ll + ts.tv_nsec);
}

I beat, it will be faster than current implementation, although I did not check yet.

[vstinner]

I'm not sure what this issue is about. If you want to propose a change, go ahead.

[socketpair]

I have checked, my optimizations give nothing, so closing the issue :(