same here

That's the final issue I have with this commit set:
utime_t is an integral part of the interface of the perf-counters.
(and - a random sampling of files that include this header show that almost all of those files make use of 'utime_t').
I am not sure it makes sense to forward-declare it here.

The header defines dozens of functions, but only 3 of those have utime_t in their signature. These 3 methods are just one special case, but not what I'd call "integral part".
Look at the heavy dependencies of utime.h - it pulls in the whole encoding/denc library with all its dependencies (= all C++ containers plus a bunch of Boost containers, the buffer library), SubProcess.h (iostreams + sstream), strtol.h (charconv!).

utime.h is one of those headers that gets included everywhere by everybody, implicitly. Yes, it is used often, but those sources that really need it should include it explicitly. Forward-declaring it from perf_counters.h helps identifying those sources that mistakenly forgot to include utime.h. That improves code correctness.

That code correctness is not just a theoretical principle; it helps finding bugs early that may occur in different build-time configurations. Ceph has lots of build failures when certain features are disabled - look at #60547 for just one of many examples (I have a dozen similar patches not-yet-submitted on my stgit stack).

One idea I'm currently exploring is making more features compile-time optional, for example ceph_assert() (see #60160); that reduces executable size (improved CPU cache hit rate, better branch prediction) and reduces runtime overhead (by omitting evaluations that are only useful in debug builds). The perf_counters feature is one such thing that could be made optional, to be disabled when performance is utterly important. Once perf_counters are optional, those missing utime.h includes will become build failures, and more build failures may sneak in at any time. Therefore, reducing header dependencies has practical advantages - it makes the build more robust.

for example ceph_assert() (see #60160);

Not related to the current PR, but still - we now use ceph_assert() with the knowledge that it will
be active in release builds. It would be a bad idea to "disappear" it (using Catch-22 phrasing)

OK - that's convincing enough
(although I don't buy in making the per_counters optional. I think there are strong reasons not to do that)

I saw how much performance can be gained by disabling assertions and (debug-)logging, and that's why we will disable both at compile time, and maybe more. If the code is correct, that's easier. Thanks for supporting my fight for better and more correct code!