From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Search takes a long time

Why does search take several minutes to search for a text string (9 occurrances were found)?  I have selected 'All VIs in Application Instance'.  There are 98 VIs in the llb file.  I'm running Windows XP on a MacBook Air.  LabVIEW 2010 SP1.  Otherwise performance is fine.

 

Thanks,

 

 - les

 

0 Kudos
Message 1 of 8
(2,669 Views)

What's a long time? Minutes? Hours?

 

The files are in an LLB? I've heard that searching through LLBs can be cumbersome because LLB have to compress and decompress the files when you write and read from them. Can anyone else confirm that is true?

0 Kudos
Message 2 of 8
(2,655 Views)

@zenthoef wrote:

What's a long time? Minutes? Hours?


 

Several minutes, perhaps 5.

 

Searching in a different llb (different application entirely) is much more reasonable - less than 20 seconds.  This llb is 1/2 the size (5 MB) and contains twice as many VIs.

 

 

0 Kudos
Message 3 of 8
(2,638 Views)

Do you have to use LLBs? I'm pretty sure the delay is coming from the compression/decompression of files as you search through the LLB, especially since the LLB that is taking longer has twice as many files. At a NI LabVIEW Developer Education Day I went to, I think this came up, but I haven't found anything online that I can reference here.

 

If you don't have to use an LLB maybe you can use a project library? I haven't used those yet, but they seem pretty good.

 

0 Kudos
Message 4 of 8
(2,628 Views)

@zenthoef wrote:

Do you have to use LLBs? I'm pretty sure the delay is coming from the compression/decompression of files as you search through the LLB, especially since the LLB that is taking longer has twice as many files. At a NI LabVIEW Developer Education Day I went to, I think this came up, but I haven't found anything online that I can reference here.

 

If you don't have to use an LLB maybe you can use a project library? I haven't used those yet, but they seem pretty good.

 


I converted from an LLB to a project library and the search is still very slow.  I have a dual core processor.  One core runs at 20-30% and the other core at 70-80% during the search.  After the search is complete both cores are running at around 2%.  The find window indicates which vi it is currently searching.  Some of the names are displayed very briefly such that they aren't readable while other names remain visible for many seconds.

 

I built an application from the project and the build completed in less than 30 seconds.

 

0 Kudos
Message 5 of 8
(2,596 Views)

Hey Les,

 

There are many things that can cause search functionality to take a long time.  The number of VI's is one thing, but also the size of the VI's, the size and type of the search text, and of course the processor and how many programs you are running.  One thing that I would try to do, is to narrow down which VI's are taking the longest and see if there is something special about those in particular.  You could take half of your VI's out and see if it takes half as long, thus a binary search of troublesome VI's.

 

Regards,

Jake

Regards,
Jake G.
National Instruments
Applications Engineer
0 Kudos
Message 6 of 8
(2,574 Views)

@TheTician wrote:

Hey Les,

 

There are many things that can cause search functionality to take a long time.  The number of VI's is one thing, but also the size of the VI's, the size and type of the search text, and of course the processor and how many programs you are running.  One thing that I would try to do, is to narrow down which VI's are taking the longest and see if there is something special about those in particular.  You could take half of your VI's out and see if it takes half as long, thus a binary search of troublesome VI's.

 

Regards,

Jake


Hi Jake,

 

Thank you for your response.  I think I have found the culprit.  These VIs all contain large (100,000 values) integer arrays.  These arrays were initialized and then the 'values made default' so that the memory remains allocated from one run to the next.  That doesn't fully explain why a STRING search takes so long since an array of U32's doesn't contain any text (aside from the label and caption).  I hesitate to suggest this, but could this be a bug in LabVIEW?

 

Searching the project for an object (loop, VI or type def) is almost instant.

 

Thanks,

 

 - les

 

0 Kudos
Message 7 of 8
(2,555 Views)

Hey Les,

 

I'm glad that we were able to determine that some VI's have large, initialized arrays.  I understand where your concern is regarding the search taking long for a STRING, when the large items are U32 arrays.  It is possible that LabVIEW iterates through every object and every element of the array regardless of the type.

 

I will look further into this matter and determine if this is expected behavior.

 

Regards,

Che T.
Applications Engineer
National Instruments
Message 8 of 8
(2,537 Views)