In my opinion, there are essentially two ways to optimize code speed:
1) Make individual pieces of code faster
This typically requires details of how the CPU itself thinks, and that tends to vary between different vendors, as others have said. You need to consider exactly what you are doing, and what the requirements are, and if there is perhaps another way to accomplish the same task. Something that optimizes code in one situation may make things worse in another.
2) change how often your code is called
Essentially, the principle here is only execute code as often as you need to. Only call your startup routine once. update your HMI only as fast as required. Realistically, 2s or more is fine for most things. Only update your inputs/outputs as often as your process can realistically handle. If you are sorting a list, you can often sort one item each scan, instead of running the whole thing at once. In general, Execute high priority sections of code more often than low priority sections of code. Many PLC's have built-in ways to help you prioritize different sections of code or equipment.
However, something to keep in mind is that there are many things you can optimize code for, depending on what you need. You can optimize for minimum memory usage, optimize for process performance. I think something that many people in this forum would advocate is to optimize for code readability.
Something else to keep in mind is that PLC hardware on the market these days have orders of magnitude more memory and speed than older generations (and at a lower price), so optimizing for speed is often far less important than it could be. It will usually take considerably more engineering time to optimize code than it would take in HW cost to just buy a faster PLC. I don't want to imply that HW cost is negligible, but I often see projects where rounding the CPU up to the next bigger one would have cost a small amount up front, and would have saved considerable money down the road.
