In Place Element Structure speed

[Drazen]

Hi everyone,

This is my first time using this forum.

I like the idea of the In Place Element Structure, and have been thinking of using it in one of my VIs to increase its speed and efficiencty. I've created a simple VI that will test its speed. It is attached bellow, speed_test.vi.

However, it performs worse than a simple pass by value code. Could someone try this simple test on their PC as well? I may be using it improperly.

Just to note, if the operation is changed from "concatinate" to just "change to upper case/lower case", it still performs the same. As well, I'm running a dual core, so each process takes up 100% of each processor.

Help would be greatly appreciated. Thanks,

-Drazen

[altenbach]

Your test is meaningless because:

1. Concatenating a string cannot be done "in place" because the memory footprint is changing.
2. The way you wire things into the inplace structure is also incorrect. You would need to wire your data that should be "in place" via a "inplace In/Inplace out" terminal pair. Right-click to create.
3. In the vast majority of times stuff that can execute in place WILL be executed "in place", even without that structure, so there will be no difference.
4. The inplace structure is a very advanced tool to be used in the very rare case when the compiler needs a hint. This is very rare and also requires you to have deep knowledge of LabVIEW. A good tool to look for problem areas is to "show buffer allocations". If there are no black dots, the inplace is not needed.
5. You have two parallel loops without a wait, meaning each loop will spin many times before releasing the CPU to the other loop. This will also depend on the number of CPUs. If you would place a 0ms wait in each loop, they will more fairly alternate on a single CPU system.
6. Since your sequence frame deals entirely with constant values, it is folded into a constant and no longer processed at runtime. That's why it is faster. It does no do anything! Place the control terminals inside the loop and convert the diagram constants to controls for a fair comparison. You should enable the display of cconstant folding to be more aware of these things (see picture below). Actually, both loops are folded, so you are basically measuring the speeed fo reading the stop boolean terminal and updating the loop counts. Not very interesting!
7. To benchmark, you should use a three-frame sequence with the testing code in the middle frame (Possibly in a loop). Take the tick count in the first and last frame and then subtract them to obtain the code duration. Make sure that all controls and indicators are ouside the sequence, and that nothing can execute in parallel to the sequence. Disable debugging and make sure youre not running any other heavy processes at the same time.

Message Edited by altenbach on 11-30-2007 09:43 AM

[Drazen]

Hi altenbach,

thanks for the reply. You're correct, I've made a few errors. It seems that resolving the folding has done it. I've placed two controls, one inside each while loop and had them run through the structures, containing the same data. It seems that the In-Place structure is 2% faster in this case. You can take a look at my vi here. The wiring was just a mistake I didn't save in the file.

Thanks,

[altenbach]

Still, if you look at the buffer allocations, the inplace structure does not gain anything. It is more useful for numeric arrays instead of strings. A 2% difference is meaningless. (the difference is a bit larger if you disable debugging, but still irrelevant).

Nobody in his right mind would complicate the code to gain 2%! Proper use of the inplace structure can easily gain you factors of two or orders of magnitude. Most of the time it is not needed because the compiler is smart enough to do things inplace if it is deemed safe.

As I said, you need to test one algorithm at a time. Running both in parallel is meaningless. I also would not bother with string operations for this.

[altenbach]

---

altenbach wrote:

 A 2% difference is meaningless. (the difference is a bit larger if you disable debugging, but still irrelevant).

---

Just to clarify more, the differences are possibly due to scheduling or other issues and have nothing to do with your string code. If you delete all string code from both loops, the lower loop is still slightly faster. 😮 The string operations are peanuts compared with spinning the loop, reading the stop terminals and updating the display, so you are basically trying to measure something tiny over a huge background.

[Drazen]

You're right the 2% is meaningless, but this was just a test scenario. Maybe leaving the loops running for a long time with statistically even out the gui updates, and other background processes. The application I am working on needs to go through large files and play around with the data, so I was just seeing if this structure could help. Unfortunately, while experimenting with it, I found a major logic flaw (unrelated), that was slowing down my algorithm, which was bringing me here. Things are okay now.