Search the Community

A script that I wrote runs recursively over all the vis in a project and searches a string in the label/description etc. It works just fine but the script opens each vi while accessing its reference and thus running over >1000 big vis takes ages. However, the built in find option in LV searches text in an application and it only takes seconds thus I guess it searches the serialized vis and somehow knows how to highlight the relevant control. Besides looking at the flattened code from time to time I never tried anything like that. Is the search function open source and I just need to find it or is it a LV secret?

I am writing a performance-sensitive application which requires the use of a nearest-neighbor lookup. Originally I used a brute-force method, but unfortunately this gets to be very slow as the data size increases . I have a point cloud of ~100k points in 2D, and need around 50k nearest neighbor lookups per second as a minimum performance requirement. As a solution I wrote a kd-tree in .Net and used LabView to call the .Net dll. However, I discovered that each .Net transaction carries with it about a 0.5ms delay. I've tried bunching the data up into groups, but this only helps so much, as I am using an iterative process. Armed with my new-found kd-tree knowledge, I then wrote the kd-tree in LV-OOP, using DVRs for both subtrees and leaf values. However, my LV implementation is still 100x slower than the .Net implementation, and 20x slower than brute force. And this is with just 10k points. I'm fairly new to LV (about 6 months in an academic environment) and I'm fairly sure I've made a massive blunder somewhere, but I don't have any idea what it might be. http://robowiki.net/...d-tree_Tutorial is the tutorial that I used for writing both trees - note that I've only implemented a 1-NN lookup method, so have no need for the priority queue. Just some notes: I found using in-place data structure unbundle-bundle was much faster than using normal unbundle-bundle for all of the read/writes. The tree started out with pure by-value subtrees and data, so was even slower before I changed to DVRs. The lookup uses a queue as a stack, rather than being recursive. Not sure if this is good or bad. The add element uses recursion. Again, not sure if this is good or bad. I've written speed tests for brute force, .Net and LV lookups with names like with test_...... .vi if you want to compare performance. kd_tree Folder.zip Thanks in advance for any help Julian Kent