What PLC scan time are you needing to hit? Do you have a ton of PID loops?
Write your code so it makes sense, THEN decide to optimize if it is too slow.
It sounds like you are simply moving the raw WX analog into the PID .PV floating point member? Working in Engineering Units is much easier than raw analog (tuning, monitoring, etc.). The PID calculations are floating point, so even raw analog 0-4095 are converted to 0.0 to 4095.0 anyway, so I recommend scaling inside the PID instruction itself for the .PV. The PID .Output is always a float 0.0 to 100.0 (percentage), so it most likely needs to be scaled regardless. If you need to do any CLAMPing on the .Output or WY, or RAMPSOAKing on the .PV, or non-linear scaling on the PV (e.g. need to use MATH or LERP on raw analog to help "linearize" it), definitely do that OUTSIDE the PID instruction. The hit to PLC scan for all of these is minimal, unless you have 10, 20, 50 PID loops and your PLC scan time is getting too high, then you need to analyze your code a little first before addressing one specific area.
The point here is that where you think you want to optimize is usually not the "slowest" code.
If the PLC scan is too slow, you need to apply Pareto Analysis (80/20 rule - 80% of the PLC scan time is in 20% of the code). Scaling a floating point number in a SCALE vs. PID vs. MATH is minimal compared to a bunch of STRING operations or copying a ton of bits in a range (for example). Hence, spending a bunch of engineering time on something that is not that much of a hit to PLC scan time is not productive.
Here's a previous post about optimization that could be of help (if actually needed):
https://forum.hosteng.com/index.php?topic=3138.msg24233#msg24233