| I was writing some services for my Class Library at work and one of the
services was very complicated with 12 event types that it responded to. I had all these
event types in a large case statement and it was starting to get unwieldy. I was about to
change the code to call a series of functions when I thought about using events of the
same name as the data values in my CASE statement. This would have the same effect as
moving the code into functions, giving me the readability and smaller script overhead and
also remove the need for PB to execute the large CASE statement. For Example:
CHOOSE CASE ls_Event
CASE 'clicked'
...
CASE 'rowfocuschanged'
...
...
...
END CHOOSE
Would be changed to
ll_RC = this.TriggerEvent( ls_Event )
Using trigger event allows me to trigger for all event types without having to examine
if this service handles the event type, this is because the TriggerEvent function will
return a -1 if the event does not exist.
I did some timings to support my theory and found that for more than 4 items in a case
statement a trigger event was actually faster than the CASE statement alone. This does not
take into account the overhead reduction of separating the scripts, so actually you get a
double performance boost.
Here are the timings:
| Iterations |
Num CASE |
Case Speed |
Event Speed |
| 50 |
5 |
4467 |
4136 |
| 100 |
5 |
8963 |
8202 |
| 100 |
7 |
12327 |
11397 |
| 100 |
10 |
18006 |
16214 |
|