Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default buffer size of getcwd for linux #92672

Closed
inteon opened this issue Jan 8, 2022 · 4 comments
Closed

Default buffer size of getcwd for linux #92672

inteon opened this issue Jan 8, 2022 · 4 comments

Comments

@inteon
Copy link
Contributor

inteon commented Jan 8, 2022

It seems like, by default, the initial buffer size for the return value of getcwd is set to 512 bytes:

let mut buf = Vec::with_capacity(512);

The default in glibc is defined as follows (https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/getcwd.c.html#61):

MAX (PATH_MAX, __getpagesize ())

This might cause some unnecessary linux kernel context switches for longer paths (multiple buffer resizes).
Is there a reason for not using a larger buffer (eg. identical to the glibc implementation)?

@the8472
Copy link
Member

the8472 commented Jan 9, 2022

This should only make a difference for code that calls it in a loop, does that happen somewhere where it's not easily fixed?

@inteon
Copy link
Contributor Author

inteon commented Jan 9, 2022

ref: denoland/deno#12056

Also, I'm asking this question out of curiosity, what is the main reason for the 512 bytes value?
It seems like most implementations use the PATH_MAX value, eg. Golang uses Getwd (https://go.dev/src/os/getwd.go).

@the8472
Copy link
Member

the8472 commented Jan 9, 2022

See the discussion in #27930 which originally implemented it.

@inteon
Copy link
Contributor Author

inteon commented Jan 9, 2022

See the discussion in #27930 which originally implemented it.

Thank you for the info, I'll do some further testing & create a PR in case I find something valuable.

@inteon inteon closed this as completed Jan 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants