I dont think speed was an issue here. I believe its more of a style thing. People dont like to use Goto. Also if you have a multiple number of steps that are dependant on the same precondition, its better to make one check then do all releated steps rather than have the same precondition on each step.
In you example I wouldn't have thought there was much of a speed difference. What have you noticed?
I did not noticed any particular difference for the simple reason I did not try it. The reason I am asking is that we are doing lots of executions in parallel. Note that these are all independant single executions.
We discovered that when we have multiple executions, the performance of TestStand is going down (when we have 12 executions, TestStand can be around 40 time slower to do a single addition; and there is no Tracing...). Now, we do try do save time everywhere we can. I already have "if-end" statements all over the place, lots of them being applied to only one step (just as my example). Some of these conditions are in for loops. So it can be repeated many times.
As we have tons of sequences, I don't want to proceed to this change (if ->precondition) for nothing. If TestStand tells me that we save 100 milliseconds by using precondition, then I will do the change because in total, it can represents minutes.
More threads mean more speed if:
- the number of computationally busy threads doesn't exceed the number of CPUs/cores
- the amount of computation in each step is not insignification compared to overhead of implicit and explicit data protection (locks, cache refreshes, ...) and context switching.
If your steps do anything computationally significant or if they wait for I/O, then these conditions are easy to meet. However, if you benchmark steps that are effectively "empty", then all you will measure is the inherent overhead, which will be large in comparision to the effectively empty steps.
I don't understand wverything you say here. First, are you telling me that the number of execution in parallel should not exceed the number of CPU cores? Also, I don't get the explanation with eefectively empty steps and the overhead associate to it. Do you mean that the overhead created by a precondition on a statement is bigger than having a step "if", a statement step and an "end" step?
1. I'm not saying that the number of executions shouldn't exceed the number of cores. Executions typically block waiting for disk, instrument I/O, shared resources, etc. In this case, it is good to have another thread available to use the otherwise idle core. However, if you generate a test case of multiple threads doing nothing but continuous computations (teststand or not), you will see not see a speed up after you run out of cores. In fact, the context switching involved in sharing the few cores among the many threads will start to decrease overall throughput.
2. I wasn't specifically saying anything about Preconditions or If's. To execute each step, TestStand accesses data about the step's properties and about the module to call. This data is protected by thread locks, which is the reason you can set property and variables from any TestStand thread and not worry about corrupting the state of the individual values. However, providing this protection means that when multiple threads try to access the same data or locks, one thread must briefly wait for the other, even if they are on different cores. Accessing this data doesn't take a long time in absolute terms, but if the step module itself is doing nearly nothing, then this overhead will dominate your measurements and the period of time that the cores can execute independently will be at its minimum.
While the points above will be true regardless, we are investigating the performance results that I believe you reported to our PSE.
I am interested to know what is the "Best Practice" or Pros and Cons when we should use Precondition or when we should use IF statement..