LabVIEW
What function searches string the fastest?
@kosist90 wrote:
I didn't think, that output of function is important in this case...
Sometimes it is. The compiler can perform "dead code elimination" and thus can remove parts from the compiled code where the output is not used and thus the presence of the code is irrelevant for the outcome. Same with constant folding that has been mentioned. You get artificially fast results.
Even if these things don't happen in your case, testing with such a short string mostly measures the subVI call overhead so you don't get accurate relative speeds anyway. I don't understand why you even use a subVI here.
Well attached is my timing test using a pattern I've used before. Instead of performing a search once and then seeing how long it takes, I perform many searches and see how long it takes for all of the searches to complete with randomized data. It still might be better to randomize the data between function runs but I think this is fine. This is also with debugging and automatic error handling off, and not updating any controls until after the timing is done.
On my machine doing 1,000,000 searches on 10 character strings, looking for two of them, here are my times in seconds.
For me GPower and Search/Split are just about the same, but since GPower calls the Search/Split I'd assume it should never be faster than just that one primitive.
But one added benefit is if you are only looking for one character, you can right click the Search/Split and it gets a bit more of a performance boost. Be careful when using this because if the search string is multiple characters, it sill only look at the first one. Also the icon doesn't change how it looks when this is enabled so it might lead to issues. Even so here is my results for searching for just 'A', using the added performance of only searching for that one character.
Because the option to look for a single character is a compiler optimization, and not an input to the function, adding this to something like the OpenG, or GPower function would mean implementing two functions, one for multicharacter and one for single character and then selecting it with something like a polymorphic selector. It could be automatic with a case select but there might be more loss in performing a string length, and comparing it to 1, than then benefit of using that function.
(and before anyone makes fun of me this is the only place I use a stacked sequence structure ever)
EDIT: Actually I just did a check to see if there is a speed difference between using Search/Split on a single character, and using Search/Split in a case structure which checks the string length and uses a single character if it is 1, and the time difference was almost nothing. I think I'd suggest OpenG and GPower add this so their search functions can work faster on single character searches.
Your technique is interesting but still not the fastest for the types of random strings generated. Also I think you misunderstood my intent. I know my example code has an array of strings it is going through but the purpose of this is just to make the processing time be longer giving us more samples. Each technique is put into a for loop and forced to iterate over each string one at a time. If it takes 0.023s for 1,000,000 strings that are 10 characters each, then it takes roughly 0.000000023s for a single string. Yes for look ups Variants are the way to go, but the intent of this is to just benchmark if a substring is inside a string
But for the heck of it I did update my code to have a few more techniques including yours. I added your method (improving it a bit by adding the Match Single Character, and Search/Split instead of Pattern Match).
I also added two other methods to compare the different ways a Search/Split string can be done. One never has the Match Single Character, one checks before every search if the string size is 1, and another checks if the search string is one once.
With one character search here are the results.
And here are the results for a 3 character search.
The result is that the fastest method is always the Search/Split where we decide to use single character match once. But this is a bit of an artificial test since I think the majority of the time a more realistic test would be to have to check the string size for each search which is the Search/Split Check Size Time which is a very close second being 1ms slower for a single character (again with 1M searches).
After all the permutations of Search/String, the GPower seems the next fastest, then Ben's Search technique which uses a technique that might work better based on the types of strings you are searching. My random 10 characters may do better or worst depending on how often a character is that we are searching is found. Then Match Pattern, Search and Replace, and then OpenG. If OpenG is inlined it's speed is close to the GPower, and Search/Split methods.
So I think the answer is to use Search/Split, and for the best results enable the Match Single Character if you know there is one character, or make a subVI that decides to match a single character if the string length is 1. Of course other techniques like Ben's will fair better depending on the types of strings, and search string used, so it is possible a more custom solution will be faster.
