in reply to "my" cost
The my has both a compile time as well as runtime affect. At compile time it says this variable will live lexically in the declared scope. That happens once when the code is compiled to the optree. There also is a runtime effect that an opcode (opcodes?) will run which allocates that new variable on the stack/stash. It’s that extra opcode that’s making the difference between being done once before the loop versus each iteration of the loop.
In your example it’s just changing the runtime, but the difference in scoping changes the lifetime of the stored value. For instance if the stored value was an object with a destructor the first case would get (possibly) unreferenced when the next loop iteration happened, while the second would be unreferenced when each loop iteration completed. Not a big difference here but it’s worth remembering the compile/run dual nature.
Edit: Of course after submitting I remember another slightly surprising corner case: things like grep that have both an EXPR and BLOCK form the former will be similarly faster because the expression is run in the context of the enclosing block, whereas the later has to run a couple extra block enter/leave steps.
The cake is a lie.
The cake is a lie.
The cake is a lie.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: "my" cost
by Danny (Chaplain) on Aug 17, 2024 at 02:01 UTC |