How to determine what is opening tmp files when I invoke a subshell with ksh

I'm experiencing extremely sluggishness in opening subshells (by using \ \ or $( ) command substitutions in scripts) while in ksh on some Linux servers. The same problem does not exist in sh or any other shell. strace indicates that the time is due to stat and openat calls against randomly named files in /tmp. **test.sh**: echo expr 1 + 1 **command**: strace -tttT ksh test.sh **output**: . . .[snipped]. . . 1734368858.571604 stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=708608, ...}) = 0 1734368859.184765 geteuid() = 1001 1734368859.184851 getegid() = 1002 1734368859.184879 getuid() = 1001 1734368859.184913 getgid() = 1002 1734368859.184946 access("/tmp", W_OK|X_OK) = 0 1734368859.185012 getpid() = 210594 1734368859.185055 openat(AT_FDCWD, "/tmp/sf0p.si0", O_RDWR|O_CREAT|O_EXCL, 0666) = 1 1734368860.771539 unlink("/tmp/sf0p.si0") = 0 . . . Between stat and openat, my simple invocation of expr 1 + 1 **took more than 2 seconds of time.** Questions: 1. Why is ksh creating files in /tmp, whereas none of the other shells (sh, bash, csh) do that? 2. How do I start diagnosing why these operations would take 1-2 seconds? Server in question is at version: Linux 5.4.17-2136.322.6.4.el8uek.x86_64 (distribution Oracle Linux Server release 8.9). Ksh is version AJM 93u+ 2012-08-01 **Update:** We've seen some artifacts of python creating empty directories under /tmp, which a few days ago I found to number 10,000 subdirs under /tmp. I deleted them all but it did not help performance. Forgive my lack of Unix knowledge, but am I right in assuming that once the directory inode is enlarged to list such an extensive # of subdirs/files, deleting those doesn't shrink the directory inode itself, but leaves a sparse structure that still has to be scanned through by all file accesses? The inode size of my /tmp (ls -ld /tmp) is currently 708KB. That's 172x larger than the starting size of 4096 bytes. Could that be what's slowing down stat and openat calls that hit /tmp ?