No, it's an even better idea to do it at compile time if the list is large. The larger the list, the larger the potential savings by precomputing it once at compile time.

Yes, it is such a better idea that the following code consumes tons of resources and then dies, perhaps taking out a few other things because you've run out of some global resource:

sub rarelyUsed {
    my @huge;  # Actually, it is usually empty
    if( ... ) {
        @huge= ('a'..'zzzz');
    } elsif( ... ) {
        @huge= ('b'..'zzzzz');
    } elsif( ... ) {
        @huge= ('c'..'zzzzzz');
    }
    ...
}
[download]

Because computing 3 huge lists is so much better than likely computing none of them or just computing one of them. (:

Just like it is so good that using "perl -c" can die horribly and slowly because of a typo, especially since it is supposed to be useful for looking for typos.

Now, I might consider it a good idea if the list were pre-computed the first time it gets evaluated rather than when it gets compiled. But barring such an intelligent optimization, I'd settle for having a reasonable maximum size enforced for this "optimization".

Would you rather find that typo the first time you compile the script, or some unspecified time later, maybe in production, when the rare case happens?