|XP is just a number|
All tasks are simple ... if you're not the one doing the work. Sure, there's enough information for perl to do the optimization you suggest. In fact, there may be enough information for it to simplify the code to:
However, code optimization is harder than it looks. Notice that both say and time are calls to other code, which could possibly change @a. Not in this case, obviously, but for perl to know that a priori, it would have to track whether or not @a was possibly aliased to another glob. Using static analysis, that could be determined, except that perl has features that may make static analysis intractable or impossible.
Disclaimer: I know nothing substantial about the internals of perl. I wrote a compiler some years ago, and spent a little (very little) time trying to put in some optimization. It was shortly after reading the Dragon book . When you read the book and start imagining the data structures and algorithms you need to build it gives you a good appreciation of the problem.
It's easy to go down rabbit-holes, too. How much time should it work on optimizing the code? If there are easy optimizations with big payoffs, then it's a no brainer. But after a while, you'll start running into diminishing returns. If you spend too much time on the optimization phase, then you can lose more time than you save.
When you don't get enough sleep for an extended period of time, your posts can come off as a bunch of stream-of-consciousness blather.