Related Issues

• os/user: very slow user.Current() on Windows #5298 (closed)
• os/user: On windows, current() -> t.GetUserProfileDirectory() errors when for RemoteInteractive Logon session on system without user profile #37348
• os/user: test fails on windows #4113 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

cc @golang/windows

I think we will need a proposal for an alternate API. See https://go.dev/s/proposal.

I traced it down to all of them depending on glog, which calls user.Current() in its init function.

Is it possible to adjust glog code to use something different from user.Current() that will provide the same functionality?

Alex

It seems that the problem relies on the fact that user.Current() tries to make network calls to deal with active directory and domain lookup. I think a new alternate api would be a "local only" version of user.Current that does not use the network.

I traced it down to all of them depending on glog, which calls user.Current() in its init function.

Is it possible to adjust glog code to use something different from user.Current() that will provide the same functionality?

Alex

Looks like kubernetes/klog (a fork of golang/glog) already applies a hack to bypass this https://github.com/kubernetes/klog/pull/123/files#diff-d01d6fd256d313607b4da3fdc0147234f5c8c4326b18044201af6da8a69ae36aR63-R84.

Change https://go.dev/cl/597255 mentions this issue: os/user: speed up Current on Windows

I've taken a stab at this in https://go-review.googlesource.com/c/go/+/597255. It replaces the offending slow API calls with GetUserNameExW, which should be faster for the current user.

@philwo could you give it a try? You can test test it compiling the Go toolchain at that CL by following these steps:

1. go install golang.org/dl/gotip@latest
2. gotip download 597255
3. gotip build .

(Replace step 3 arguments with whatever build args you are using to build your app).

Hi @qmuntal,

Wow, thank you so much for quickly finding & implementing this fix. I've tested it on the corporate Windows machine that showed the performance issues. Your CL is a huge improvement for me in all cases.

First, I compared that the output of user.Current() is the same before and after the change. They match exactly. ✅

Then I compared the performance:

# Before change, "best case" (working connection to Active Directory)
> hyperfine .\getuser.exe
Benchmark 1: .\getuser.exe
  Time (mean ± σ):     528.5 ms ±   1.7 ms    [User: 0.0 ms, System: 1.6 ms]
  Range (min … max):   526.2 ms … 531.7 ms    10 runs

# After change, "best case" shows a ~50x speed-up
> hyperfine .\getuser_fixed.exe
Benchmark 1: .\getuser_fixed.exe
  Time (mean ± σ):      10.0 ms ±   0.6 ms    [User: 0.3 ms, System: 0.3 ms]
  Range (min … max):     8.6 ms …  13.4 ms    154 runs

# Before change, "worst case" (connection to Active Directory disrupted)
> hyperfine --runs=1 .\getuser.exe
Benchmark 1: .\getuser.exe
  Time (abs ≡):        22.529 s               [User: 0.000 s, System: 0.000 s]

# After change, "worst case" shows a >200x speed-up
> hyperfine .\getuser_fixed.exe
Benchmark 1: .\getuser_fixed.exe
  Time (mean ± σ):       9.5 ms ±   0.6 ms    [User: 0.2 ms, System: 0.1 ms]
  Range (min … max):     8.4 ms …  13.2 ms    154 runs

So impressive! 🚀

For comparison, I also benchmarked the problematic workaround that some people use, which is to rely on the %USERNAME% environment variable on Windows. The performance as measured by the above benchmark is the same, so I can't think of a good reason to keep using %USERNAME%.

I think this will not only result in an ecosystem-wide startup time improvement of Go tools running on Windows that were affected by this, but if we can get folks to revert their workarounds that depend on %USERNAME%, it will improve security as well, because...

> .\getuser_from_envvar.exe
Result: philwo
> set USERNAME=mallory
> .\getuser_from_envvar.exe
Result: mallory

😅

Thanks,
Philipp

Wow, thank you so much for quickly finding & implementing this fix.

Glad that it helped 😸, thanks for testing it. I'm afraid it is too late to merge the fix into go1.23 release branch, unless the @golang/release team thinks it worth the risk.

Change https://go.dev/cl/604395 mentions this issue: os/user: document Current improvements

Reopen due to CL 604555. I'll prepare a CL with another attempt soon.

Change https://go.dev/cl/604555 mentions this issue: Revert "os/user: speed up Current on Windows"

Change https://go.dev/cl/605135 mentions this issue: os/user: speed up Current on Windows

a96e736

func GetUserName(format uint32) (string, error) {
	n := uint32(50)

@qmuntal
instead of 50, should that have been UNLEN + 1, which is 256 + 1?

A pointer to the buffer to receive the user's logon name. If this buffer is not large enough to contain the entire user name, the function fails. A buffer size of (UNLEN + 1) characters will hold the maximum length user name including the terminating null character. UNLEN is defined in Lmcons.h.

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getusernamea#parameters

@neolit123

instead of 50, should that have been UNLEN + 1, which is 256 + 1?

Why 257?

257 is too large for an average user name. We start with 50 and grow only if 50 is not large enough.

Alex

@neolit123

instead of 50, should that have been UNLEN + 1, which is 256 + 1?

Why 257?

257 is too large for an average user name. We start with 50 and grow only if 50 is not large enough.

Alex

i missed this part of the function docs, that n will receive the req size.

If lpNameBuffer is too small, the function fails and GetLastError returns ERROR_MORE_DATA. This parameter receives the required buffer size, in Unicode characters (whether or not Unicode is being used), including the terminating null character.

https://learn.microsoft.com/en-us/windows/win32/api/secext/nf-secext-getusernameexa#parameters