Question
How can the performance of Apex switch statements be compared to if‑else chains when invoked from Lightning Web Components?
Rey Nova
0 reputation · 09 Oct 2021, 15:38 UTC
20K views1
Loading…
0 reputation · 09 Oct 2021, 15:38 UTC
Measuring performance differences between Apex switch and if‑else constructs requires identical test data, two Apex methods that return the same type, and invocation from an LWC via the wire service where the result is accessed through the .data property. The benchmark must control for warm‑up effects, network latency, and ensure both methods produce matching output to validate the comparison.
What iteration count provides statistically reliable timing measurements for each method? How should the wire service be invoked to isolate Apex execution time from Proxy .data access overhead? Should the measurement include or exclude the Proxy data retrieval step?
26525 reputation · 09 Oct 2021, 19:13 UTC
For a statistically reliable comparison you should run each Apex method at least 1,000 imperative invocations, discarding the first 50 as warm‑up. Measure the CPU time from Apex debug logs – that isolates the server‑side cost and excludes the LWC Proxy’s .data access overhead. Do not include the Proxy data retrieval step in the timing if you want to assess pure Apex performance.
apeximport mySwitch from '@salesforce/apex/MyCtrl.mySwitch';
import myIf from '@salesforce/apex/MyCtrl.myIf';
FINEST for Apex, and ensure CPU Time is logged.Thread.sleep(5) inside each branch to magnify measurable differences if the original difference is too small.debug logs to read the CPU Time field; this represents the time spent executing Apex on the server..data property access on the proxy – that is client‑side JavaScript and is not part of the Apex execution cost.console.time around proxy.data) from the total wall‑time.How many distinct constant cases does your switch statement contain? The CPU advantage grows with the number of branches, so knowing the exact count will help you decide whether the effort to benchmark is worthwhile.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 09 Oct 2021, 23:34 UTC
When you call an Apex method from a Lightning Web Component the round‑trip time you see in the browser is dominated by network latency and the wire adapter’s proxy handling. If you want to compare the pure server‑side cost of a switch versus an if‑else chain you must strip those layers out.
Write two @IsTest methods, each wrapping the same helper method in a for loop of 10 000 iterations. Surround the loop with Test.startTest() and Test.stopTest() so the governor limits are applied only to the loop body. Inside the helper method keep the logic identical – the only difference is the switch versus if‑else.
@IsTest
private static void testSwitchVsIfElse() {
Test.startTest();
for (Integer i=0; i<10000; i++) {
MyCtrl.doSwitch(i);
}
Test.stopTest();
}
Enable FINEST Apex logging and look for the CPU Time entry for each method in the debug log. The difference in CPU units is the metric you want; it excludes any client‑side or wire‑adapter overhead.
To confirm that the difference is negligible for end users, create an LWC that imperatively calls the two methods in a single user session and use the browser’s Network panel to record the total response time. You should see total latency differences well under 10 ms, even if the Apex CPU varies by a few hundred units.