LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Big Performance Degradation in LabVIEW 2012

Solved!
Go to solution

I have used 7.1 but not below that. Ok if we start this discussion it will keep going may be later on Breakpoint. Now I am curious to see your comments on the Benchmarking

-----

The best solution is the one you find it by yourself
0 Kudos
Message 11 of 111
(5,684 Views)

I am glad i did not promise anything!

 

The only thing I can offer is to

 

1) try putting a "0 ms wait" in the while loops where you are doing the increments to help out with cooperative multi-tasking. It help with the process scheduling.

2) Make sure you have turned off debugging etc in both versions.

3) I believe there was a change implemented with the type cast that may be part of the explanation if your results still look bad for 2012. I can not be sure since I was told a bug I uncovered that allowed breaking some the LVOOP contracts would be fixed but I did not here back so I admit I am speculating.

 

In the meantime i will falg NI to look at this closer and either explain or log this a performance bug.

 

Sorry but that is all I can do.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 12 of 111
(5,661 Views)

Thanks, Ben

 

It's also my suspicion that the culprit could be the type cast, method override or queue operations that somewhere along the line got a performance hit for LV2012?

 

Or perhaps it could be an overly aggressive memory size optimization in the runtime, which gives an execution speed penalty?

Maybe LV 2012 is too C/C++ 'delete/free' trigger happy? 🙂

 

Well... I'll keep scratching my ignorant head over this one... Smiley Sad

 

Let's see what NI's got to say about this.

 

Br,

 

/Roger

 

0 Kudos
Message 13 of 111
(5,653 Views)

When I notified NI I told them;

 

"We either have a bug or a leson to learn."

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 14 of 111
(5,646 Views)
Just to rule out the obvious, have you mass compiled and saved the VIs in LV12? Opening a VI in a new version puts all subVI FP in memory which can slow things down, much like benchmarking with SubVIs open will.
Message 15 of 111
(5,618 Views)

Darin.K wrote:
Just to rule out the obvious, have you mass compiled and saved the VIs in LV12? Opening a VI in a new version puts all subVI FP in memory which can slow things down, much like benchmarking with SubVIs open will.


 

I got the imprdion this runs on a RT platform in which case that should be covered when compiled and downloaded... of course I may be wrong about either of those points.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 16 of 111
(5,595 Views)
Now that I squint at those images on my phone, it does look like it is indeed RT.
0 Kudos
Message 17 of 111
(5,580 Views)

The performance drop is most noticeable on more computationally constrained RT targets, such as the sbRIO 9606.

On my "real" c/sbRIO customer projects/programs where I previously was utilizing about 30-40% of CPU, now flatlines at 100%.

 

Br,

 

/Roger

 

0 Kudos
Message 18 of 111
(5,539 Views)

@User002 wrote:

The performance drop is most noticeable on more computationally constrained RT targets, such as the sbRIO 9606.

On my "real" c/sbRIO customer projects/programs where I previously was utilizing about 30-40% of CPU, now flatlines at 100%.

 

Br,

 

/Roger

 


Please try putting "0 ms wait"s in those loops.

 

Please.

 

The "0 ms wait" only marks the end of the loop so the task scheduler can do it job without preempting etc.

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 19 of 111
(5,489 Views)

Did that yesterday.

 

The performance went down even further (some 20%), since we are forcing the scheduler to run between each iteration I presume?

 

Br,

 

/Roger

 


@Ben wrote:

@User002 wrote:

The performance drop is most noticeable on more computationally constrained RT targets, such as the sbRIO 9606.

On my "real" c/sbRIO customer projects/programs where I previously was utilizing about 30-40% of CPU, now flatlines at 100%.

 

Br,

 

/Roger

 


Please try putting "0 ms wait"s in those loops.

 

Please.

 

The "0 ms wait" only marks the end of the loop so the task scheduler can do it job without preempting etc.

 

Ben 




 

0 Kudos
Message 20 of 111
(5,486 Views)