<@U021C96KUGJ>: re: `experimental_shell_command`
# development
w
@ancient-vegetable-10556: re:
experimental_shell_command
the thing that is actually using immutable inputs in your repro is
experimental_run_shell_command
and it will use them in all three runs, afaik
a
There’s nothing immutable to input until the first run
w
right. so during the first run, you will pay the cost to create the immutable input. but the second run should be able to just use it
a
OK, so it’s probably only deciding to make an input immutable when it gets retrieved from the cache
which is what my understanding of the behaviour was until just now
w
that shouldn’t be the case
which is why it’s slightly odd.
b
Wait my understanding aligns with Chriss?
w
i’m suspecting some noise from a background process perhaps
b
We don't make the immut input until it's needed as an input
a
Stu — rightly — points out that it is an input
w
right: but each of the three runs involves two processes: an
experimental_shell_command
, and an
experimental_run_shell_command
to consume it
b
Ah, I'm missing some context. Somewhat ignore me
a
@witty-crayon-22786 Give me a moment, I can test to see if it’s a timing issue
will be a few minutes while I investigate
b
So yeah run 2 and 3 should have the run process sped up and the non-run be memoized
w
right
b
Good chance there's bugs. I still wanna write tests for this.
a
OK, I now have a graph that looks like this:
Copy code
A -> B
A -> C
B -> C

A = `yarn install --immutable`
B = `sleep 5`
C = `ls {chroot}/`
Observations:
• The first run does indeed have symlinks in the output. Good! • There’s still the three-step speedup that we saw without the indirection.
w
would need to look at traces and/or profiles i think. my guess is a background process of some sort
but in any case: immutable inputs are working there
thanks for confirming!
👍 1
b
New comit will be coming in very soon with dirsize caching.
very soon => soonish (writing tests so I feel better about it)
OK added tests 🙂