LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Benchmarking VI (getting offset each time when benchmarking)

Solved!
Go to solution

Here's what I had in mind, see if it makes sense. 😉

 

 

There is still a weird observation:

 From the second benchmark on, the very fist time is slow (~500-1000ms, the first run is always fast!).

I am not quite sure why.... Anyone??

Message 21 of 24
(1,035 Views)

Ya I noticed that also, I don't know why it is... it doesn't depend on the VI you are benchmarking either that is what I know for sure.

 

I will now check your VI and see how you had it in mind, thanks already for the help you have given me. 

0 Kudos
Message 22 of 24
(1,030 Views)

The SubVI stomps on the two string inputs (because of the To Lower Case primitive).  This causes the inplacer to decide to make a copy of the two string arrays before calling the SubVI (via CBR or normal SubVI call--it doesn't matter).

 

The inplacer decides to copy the entire string subarray, rather than just a single element.  The location of the copy dot is here:

 

21045i3027757D1446ADC6

 

If you look at the size of the arrays at runtime in the computation of one benchmark, you see that the size of the copied subarray starts at 2 and increases.  When a second benchmark is taken (this is where we see the performance hit) the subarray size restarts back at 2 and increases again.

 

In the allocator, when we grow an array of strings into a larger array of strings, we check to see if we can reuse the allocations from the previous iteration (i.e. if they are bigger or the same size).  When we shrink an array of strings, however, we must visit each element of the array to release the individual string's memory.  This is where the performance hit is originating.  I would think that this behavior has been in LabVIEW for quite awhile--well before LabVIEW 2009.

 

If you put a copy dot immediately before the SubVI call, you can avoid the performance anomaly.

 

21047iB9164D1512776DA9

 

-- Chris W

LabVIEW R&D

Message 23 of 24
(985 Views)

You are correct, the copy dot solves the problem. Very informative post also, thank you for that.

 

Does anyone have some idea's maybe for my VI? I now have the following (see download) it checks also if the all the outputs are equal to each other and are equal to the expected output.

 

I was also wondering isn't there a standard benchmark VI/tool or something provided by labview self?

0 Kudos
Message 24 of 24
(970 Views)