xcontrol: performance question (again)

[soranito]

Hello,

I've got a little performance question regarding xcontrols. I observed rather high cpu-load when using xcontrols. To investigate it further, I built a minimal xcontrol (boolean type) which only writes the received boolean-value to a display-element in it's facade (see attached example). When I use this xcontrol in a test-vi and write to it with a rate of 1000 booleans / second, I get a cpu-load of about 10%. When I write directly to a boolean display element instead of the xcontrol,I have a load of 0 to 1 %. The funny thing is, when I emulate the xcontrol functionality with a subvi, a subpanel and a queue (see example), I only have 0 to 1% cpu-load, too.

Is there a way to reduce the cpu-load when using xcontrols? 

If there isn't and if this is not a problem with my installation but a known issue, I think this would be a potential point for NI to fix in a future update of LV.

Regards,

soranito

Message Edited by soranito on 04-04-2010 08:16 PM

Message Edited by soranito on 04-04-2010 08:18 PM

[lavalava]

can you post this as 8.6?

[soranito]

Hi lavalava,

here it is as 8.6

[lavalava]

Here, I've made a few changes.  Take a look at my comments.

Message Edited by lavalava on 04-05-2010 09:53 PM

[soranito]

Hi lavalave,

thanks for the answer. I'm sorry that I wasn't clear enough with my first post. I didn't want to lower the cpu-load in this specific app, I know that I can do this with longer waits. In fact, I wanted to create some serious cpu-load so that I can  check the three possibilities (which do exactly the same) against each other regarding performance.

Well, I was a bit suprised that my quick-and-dirty approach with queue and subpanel needs about 1000 times less cpu-power than the built-in xcontrols. Sure, the subpanel-approach has no custom property-nodes like a xcontrol, but this functionality can be realized with queues, too (again: way faster than the built-in property nodes).

I'm just complaining, that NI is wasting a lot of performance here and at the moment I cannot see why this is necessary, if you can emulate the functionality with built-in LabVIEW-functions.

regards,

soranito

[Intaris]

AFAIK NIs front-panel controls do some checking in the background to minimise screen updates when they're not neccessary.

XControls do not (automatically) have this feature.

If you want to make a suggestion in the Idea Exchange that screen updates should be performed in the same way as standard controls (reducing unneccessary updates) then I'll kudo it for sure.

Everything I say is based on personal knowledge and may (at worst) be completely incorrect or (at best) kind of close to being correct. 

Shane.

[lavalava]

---

soranito wrote:

Hi lavalave,

thanks for the answer. I'm sorry that I wasn't clear enough with my first post. I didn't want to lower the cpu-load in this specific app, I know that I can do this with longer waits. In fact, I wanted to create some serious cpu-load so that I can  check the three possibilities (which do exactly the same) against each other regarding performance.

Well, I was a bit suprised that my quick-and-dirty approach with queue and subpanel needs about 1000 times less cpu-power than the built-in xcontrols. Sure, the subpanel-approach has no custom property-nodes like a xcontrol, but this functionality can be realized with queues, too (again: way faster than the built-in property nodes).

---

Really? Why would you want to do that?  If you want to load your CPU to the max then change your 1ms wait time to 0, glance over to your task manager and see your CPU resourcing hitting the roof.

If that's not enough, then create have two while loop rocking in parallel.  And if that's even not enough then create more loops running in parallel.

---

I'm just complaining, that NI is wasting a lot of performance here and at the moment I cannot see why this is necessary, if you can emulate the functionality with built-in LabVIEW-functions.

regards,

soranito

---

If you ever get a hold of someone at NI, please tell them to stress test xcontrol with more worst case senarios.  If you make your xcontrol more complicated by adding more stuffs to it.  It will corrupt your main VI that is embedding the xcontrols.  I can't recall the C error code but it basically telling us to contact NI for further help and we just simply can't retreat that VI because it's permanently deaad.  Yeah, I'm serious. Make sure you back up your works daily because that's what saved me.

[lavalava]

---

soranito wrote:

Hello,

I've got a little performance question regarding xcontrols. I observed rather high cpu-load when using xcontrols. To investigate it further, I built a minimal xcontrol (boolean type) which only writes the received boolean-value to a display-element in it's facade (see attached example). When I use this xcontrol in a test-vi and write to it with a rate of 1000 booleans / second, I get a cpu-load of about 10%. When I write directly to a boolean display element instead of the xcontrol,I have a load of 0 to 1 %. The funny thing is, when I emulate the xcontrol functionality with a subvi, a subpanel and a queue (see example), I only have 0 to 1% cpu-load, too.

---

Okay, I think I understand question  now.  You want to know why an equivalent xcontrol boolean consumes 10x more CPU resource than the LV base package boolean?

Okay, try opening the project I replied yesterday.  I don't have access to LV at my desk so let's try this. Open up your xcontrol facade.vi.  Notice how I separated up your data event into two events?  Go the data change vi event, when looping back the action, set the isDataChanged (part of the data change cluster) to FALSE.  While the data input (the one displayed on your facade.vi front panel), set that isDataChanged to TRUE.  This is will limit the number of times facade will be looping.  It will not drop your CPU down from 10% to 0% but it should drop a little, just enough to give you a short term solution.  If that doesn't work, just play around with the loopback statement.  I can't remember the exact method.

Yeah, I agree xcontrol shouldn't be overconsuming system resource.  I think xcontrol is still in its primitive form and I'm not sure if NI is planning on investing more times to bug fix or even enhance it.  Imo, I don't think xcontrol is quite ready for primetime yet.   Just too many issues that need improvement.

Message Edited by lavalava on 04-06-2010 03:34 PM

[lavalava]

Here ya go, take a look at my changes to your codes.  I got all 3 of them to running at about the same resource based on what I told you in the last post (all 0% CPU consumption, before was 6% for xcontrol case).  Keep in mind, I'm running Vista x64, Intel Quadcore 45nm, that's 4 processors running at 3.65Ghz ea, & 8GB RAM.  Even if you have a slower system, you should still see a whole lot better performance than before.

Message Edited by lavalava on 04-06-2010 09:42 PM

[FraggerFox]

---

lavalava wrote:

Keep in mind, I'm running Vista x64, Intel Quadcore 45nm, that's 4 processors running at 3.65Ghz ea, & 8GB RAM.  Even if you have a slower system, you should still see a whole lot better performance than before.

Message Edited by lavalava on 04-06-2010 09:42 PM

---

Woah!!! Mammoth Config!! 😮