LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV2 globals are slower than Globals ??

I have been reading on the pros of using the LV2 or Functional Globals .

Put together a small trial VI to check out the performance gain when using the LV2 globals. To my surprise, I find that the normal Global is faster in a write-once and read-many type application.

Am I missing out something or is it supposed to be that way ?

( Just unzip the attachment into a folder and run . Compiled with LV8.0 )

Thanks

Raghunathan
Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 1 of 9
(3,777 Views)
Hi,

No, you are not missing the point, global are very fast but they do have drawbacks.
I suggest you read this thread, it is a bit long but there are some good explanations and a benchmark that compare speed for reading different type of variable.

Hope this helps

We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

Message 2 of 9
(3,768 Views)
Hi TiTou,

Thanks for the link to the thread on a similiar topic. I sat and read through all the 4 pages. Quite interesting.

And there also the normal Global seems to shine, speedwise.

In fact I launched on this whole exercise only because we were ( and are still ) having random crashes on a code controlling an Endurance Test rig. Certain days it runs like magic and certain days it crashes as and when it likes. ( I am trying to see if the planets have any influence on the code ..) Of course we are eliminating lots of bad code : Some half a dozen property nodes were updated inside of a 50ms timer loop ; An entire array of 20 DIs were being updated by the main and read by  the active subVI at that instant passed via a Global. And the finished late LED of the 50ms timed loop used to glow always ...

It is this Global that I wanted to swap with a LV2 global and see if my 50ms timed loop was fine. I will anyway go ahead and do the change to LV2 global.

There are times when it helps to things the right way - at least you don't live with guilt !!

Regards

Raghu
Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 3 of 9
(3,742 Views)
Another surprise ( at least to me )

I changed the status of the LV2 global to "Subroutine"  and now it is quite faster than the normal Global.

Run the attached code. On my system ( P4 / 2Ghz / Win+XP / 512Mb ram ) the normal global took 119ms and the LV2 took only 101ms to complete the loop !

Now I am happy.

Raghunathan
Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 4 of 9
(3,736 Views)

Hi again,

Some of the improvements you discovered are documented here. Also, you certainly know that for each instance of a global, the memory is duplicated, so with "only" 512Mo of RAM for XP, depending on the size of the data that was handled by the global, maybe the operating system couldn't find contiguous memory, this could explain the performance hit with LV2 global.

Sounds like you've had a good day today Smiley Happy

"Knowledge is the only matters that grows when shared", Socrates Smiley Wink

 

We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

Message 5 of 9
(3,728 Views)
>> ...for each instance of a global, the memory is duplicated...

Q1 : I am reading the Global within a For loop, without modifying it. Even then does it have to make copies ?

Q2 : Once the "Read"  is over, does not  LV release the allocated memory ?

Thanks

Raghunathan
Raghunathan
LabVIEW to Automate Hydraulic Test rigs.
0 Kudos
Message 6 of 9
(3,727 Views)
R1 : One copie for each "instance", not for each "call", so my understanding is that for one instance in a loop there is only one copie in memory.

R2 : I'm not sure on that one, but in labVIEW, you normally don't explicitely allocate or deallocate memory (in fact you have to in certains cases such as image allocation), LabVIEW does it for you, so it's better to have an idea on how LV allocates memory not to blow your ram up.
I am not 100% sure, but my feeling is that the memory allocated for globals is only released when LabVIEW is closed, you can easily test that with the task manager and a small VI in which you put a very large array into a global, when the VI is launched you'll see the ram usage jump up and then see when it drops...

Hopefully someone with greater knowledge will jump in this thread and give better explanations Smiley Surprised

Hope this helps

We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

Message 7 of 9
(3,722 Views)

I think TiTou got it all right.

The description of an array boolean sounds like it problem waiting to happen. I talk about sharing digital output in my  Action Engine nugget. The example provided there may be helpful.

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 9
(3,711 Views)
I just gave an NI-Week presentation on this topic (reference objects in LabVIEW).  I posted the presentation, code and a LabVIEW 8.5 update here.  The take-home message is that globals are very fast, but I would not recommend using them, since there are better things available - specifically functional globals and single-element queues.  It is interesting to note that in fourteen years of using LabVIEW, I have never needed to use a global.  I have used them due to ignorance a couple of times, but later found a better solution.

Good luck.
Message 9 of 9
(3,656 Views)