perf(runtime): cache cwd lookups

[AaronO]

This caches CWD lookups, Deno.cwd() is ~5x faster and shaves off ~20% of read_128k_sync.

This is a first PR of a series to optimize sync file reads, optimizing cwd not only helps Deno.cwd() but it also optimizes all file IO permission checks

Bench results

# Before
cwd:                 	n = 50000, dt = 0.389s, r = 128535/s, t = 7780ns/op
read_128k_sync:      	n = 50000, dt = 1.922s, r = 26015/s, t = 38440ns/op

# After
cwd:                 	n = 50000, dt = 0.073s, r = 684932/s, t = 1460ns/op
read_128k_sync:      	n = 50000, dt = 1.591s, r = 31427/s, t = 31819ns/op

[caspervonb]

Does not seem sound as cwd can be changed from any thread in a worker.

[AaronO]

Does not seem sound as cwd can be changed from any thread in a worker.

Yep I should have explicited the assumption here, I'll change it to use a Mutex or RwLock should have roughly same performance and there shouldn't be significant contention in any real world programs

[ry]

I'm worried about this change - it might introduce some odd bugs if somehow the cwd changes outside of op_chdir.

I don't understand why caching cwd would effect readFile perf at all. readFile should not use cwd even once let alone multiple times.

[AaronO]

I'm worried about this change - it might introduce some odd bugs if somehow the cwd changes outside of op_chdir.

I don't understand why caching cwd would effect readFile perf at all. readFile should not use cwd even once let alone multiple times.

See:

optimizing cwd not only helps Deno.cwd() but it also optimizes all file IO permission checks

since file IO permission checks need to resolve the full file path, these cwd related calls accounted for ~20% of the time spent in the read_128k_sync bench, which is quite significant overhead (making us a few times slower than NodeJS for basic file IO)

[AaronO]

I'm worried about this change - it might introduce some odd bugs if somehow the cwd changes outside of op_chdir.

I don't understand why caching cwd would effect readFile perf at all. readFile should not use cwd even once let alone multiple times.

In addition, I think it's a fair assumption that the CLI should never change the CWD and thus it will only be changed by user code executed in the runtime, a lazy_static Mutex or RwLock would solve the cross-thread/worker soundness casper mentioned

[CLAassistant]

All committers have signed the CLA.

[bartlomieju]

I'm also not in favor of this change. I think we should close this PR.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.