Setting process.title is slow on Mac

[ArnaudBarre]

Version

24.7.0

Platform

Darwin Mac.local 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:49 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6000 arm6

Subsystem

No response

What steps will reproduce the bug?

const startTime = performance.now();
process.title = "node (example)";
const endTime = performance.now();
console.log(`${(endTime - startTime).toFixed(2)} ms`);

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

Should take less than 1ms (like on unix or for bun/deno on mac)

What do you see instead?

Taking 10+ ms

Additional information

https://bsky.app/profile/ariperkkio.dev/post/3lxh2n2pp5c2c

[juanarbol]

and why is this so critical? I just wanna understand

[TheAlexLichter]

Vitest does set it for each isolated test file, which makes the DX for debugging the process of the test runners better. Per-file, this can actually add up perf-wise.

Context on Bluesky (that was already linked above by Arnaud)

[juanarbol]

which makes the DX for debugging the process of the test runners better

Is this critical? The problem with the macOS implementation is not about just setting the thread title. With 1-line change I got 0ms in your script:

/* /tmp/title.js */
const startTime = performance.now();
process.title = "node (example)";
const endTime = performance.now();
console.log(`${(endTime - startTime).toFixed(2)} ms`);
console.log(process.title);

./node /tmp/title.js
0.00 ms

And this is the diff

diff --git a/deps/uv/src/unix/darwin-proctitle.c b/deps/uv/src/unix/darwin-proctitle.c
index 5e5642972a..434ac7b173 100644
--- a/deps/uv/src/unix/darwin-proctitle.c
+++ b/deps/uv/src/unix/darwin-proctitle.c
@@ -34,7 +34,7 @@
 #endif
 
 int uv__set_process_title(const char* title) {
-#if TARGET_OS_IPHONE
+#if !TARGET_OS_IPHONE
   return uv__thread_setname(title);
 #else
   CFStringRef (*pCFStringCreateWithCString)(CFAllocatorRef,
@@ -173,4 +173,4 @@ out:
 
   return err;
 #endif  /* !TARGET_OS_IPHONE */
-}
+}
\ No newline at end of file

I don't think there's too much to do. If we remove that logic, some things won't be updated, like Force Quit window, Activity Monitor, Dock hover text, etc. Which could break more stuff.

But let me do a humble ping to @nodejs/libuv

Refs: https://issues.chromium.org/issues/41063805#comment65

[bnoordhuis]

I've opened libuv/libuv#4877 that should address that, please test it.

[juanarbol]

This is about the overhead of all the private CF stuff...

Note: I just used console.time/timeEnd

$ repeat 100 ./node /tmp/title.js
title: 11.67ms
title: 10.332ms
title: 9.334ms
title: 10.034ms
title: 9.301ms
title: 9.021ms
title: 9.361ms
title: 9.143ms
title: 9.122ms
title: 9.501ms
title: 9.099ms
title: 9.319ms
title: 9.002ms
title: 9.3ms
title: 9.032ms
title: 9.051ms
title: 9.101ms
title: 9.128ms
title: 9.359ms
title: 9.277ms
title: 9.274ms
title: 9.147ms
title: 9.232ms
title: 8.966ms
title: 9.02ms
title: 8.896ms
title: 9.481ms
title: 8.958ms
title: 9.204ms
title: 9.118ms
title: 9.867ms
title: 9.016ms
title: 9.504ms
title: 8.931ms
title: 9.17ms
title: 9.188ms
title: 9.213ms
title: 9.517ms
title: 9.005ms
title: 9.418ms
title: 9.763ms
title: 9.014ms
title: 9.398ms
title: 9.506ms
title: 9.017ms
title: 8.896ms
title: 9.099ms
title: 8.896ms
title: 9.09ms
title: 9.483ms
title: 9.454ms
title: 8.972ms
title: 9.309ms
title: 9.176ms
title: 9.068ms
title: 9.055ms
title: 9.056ms
title: 9.391ms
title: 10.013ms
title: 10.134ms
title: 9.723ms
title: 10.114ms
title: 9.313ms
title: 9.254ms
title: 8.99ms
title: 9.135ms
title: 10.237ms
title: 10.52ms
title: 9.144ms
title: 9.021ms
title: 9.124ms
title: 10.131ms
title: 9.241ms
title: 9.124ms
title: 9.099ms
title: 9.149ms
title: 9.081ms
title: 9.121ms
title: 10.277ms
title: 9.243ms
title: 9.25ms
title: 9.07ms
title: 9.078ms
title: 9.264ms
title: 9.207ms
title: 9.152ms
title: 9.241ms
title: 9.235ms
title: 9.313ms
title: 9.152ms
title: 9.391ms
title: 9.255ms
title: 9.342ms
title: 9.111ms
title: 9.212ms
title: 9.276ms
title: 8.963ms
title: 9.148ms
title: 9.293ms
title: 9.174ms

[sheremet-va]

As a maintainer of Vitest, I just want to add a few points:

• This is not a critical issue and I am not sure why it needs be critical to have an open issue.
• The setter is not called multiple times per second, it is called once at the start of a new process. There could be several (not hundreds) processes in parallel, but they are isolated from each other.
• Thank you for looking in this.