xperience, we can define a checklist of commonly used strategies to get the opti- mum performance out of application software: Use the optimizer. Some programmers avoid compiler optimization for various reasons. Historically, some optimizers have caused logic problems. Performance-centrio applications should all be compiled with the -03 optimization level unless there is an explainable reason why not to. We recommend that this level of optimization be used for almost all circumstances. Avoid branches where possible. Branches cause instruction memory stalls depending on the target address. The programmer may know in advance which code path is the more likely to occur. In that case, the code can be structured to execute that path first, thus eliminating some run-time testing and branching. A common example where you can eliminate dynamic branches is in cascaded if-then-else statements. For example: Chapter 9 Software performance 323 if (bar = ==0) almost never get here else if (bar < 0) sometimes get here almost always get here is better rewritten as: if (bar >0) almost always get here else if (bar <0) sometimes get here almost never get here. To keep the code more readable even with complex if-then-else statements and without having to refactor or retest code, use the likely/unlikely compiler hints. In fact, this makes the code more readable because the most likely path is visible to the observer. Avoid branches by making one code path common and only test one condition. So, the following code snippet: if (condition) x = 2; Could be rewritten more efficiently as: if (condition) x = 1; Avoid switch/case constructs like the following, especially for small code segments. Although the source is clear, it generates numerous tests and branches that make it ineffi- cient. It also does not distinguish the most likely, or "hot" path from others. switch (var) { case 0: x=1; break; case 1: x = 2; break; case 4: x=9; break; default: X = 12; break; 324 Open Radio Access Network (O-RAN) Systems Architecture and Design Consolida