LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Count lines in text file

 
As I suspected, the array size method is not very optimal. Out of curiosity, I wrote 8 different ways to count lines (defined as seperated by "\n"). All give the same result on a 1.3MB text file with about  20000 lines. The first 6 versions are shown here and the fastest and slowest version are in the next post below.
 
The image show the various code fragments to count the lines.
 
Here are the results in milliseconds for the above file input (look at the case for the names):
 
  1. "SearchU8" is fastest at 9ms
  2. "replaceAll" is second at 12ms, however if I don't wire the "replace string" input, it is 20ms.
  3. "Pattern" is third at 20ms.
  4. "sum" is in fourth place at 25ms, however if we expect more than 32767lines, we need to insert a "To I32", slowing it to 38ms.
  5. "StringArray" is quite slow at 158ms (as I suspected! ;)).
  6. "SearchString is dead last with 140000ms!!! Almost 2.5minutes!, (It goes down to 50000ms if I wire the \n also to the "replace string" terminal (and remove the +1 and check for <0 for loop termination etc. as needed)).
In summary, there are big differences and the simples code is not necessarily the fastest. 😄
 
 
 
This is under LabVIEW 8.20. As always, your mileage may vary. 😉
 

Message Edited by altenbach on 09-29-2006 05:39 PM

Message 11 of 15
(5,985 Views)

OK, the fastest and slowest so far were not included in the previous post. 🙂

So, for completeness....

  1. "match": Match pattern is actually the fastest a 8ms.
  2. "regex": is slowest at 335000ms.

Message Edited by altenbach on 09-29-2006 09:47 PM

Message 12 of 15
(5,975 Views)
I felt like resurrecting this nice simple little thread...sometimes the simplest code is not the most optimum.  Altenbach, very nice bench marking!  -SS


0 Kudos
Message 13 of 15
(5,633 Views)

Thanks a lot for taking the time to do this, really appreciated and a very useful bit of code - good to actually see the execution time measured. 

0 Kudos
Message 14 of 15
(3,513 Views)

On that regex being the slowest, would it still be the slowest if you anchored the match to the end of the string as in like using this as the regular expression "\n$" or even "$" ?

0 Kudos
Message 15 of 15
(2,478 Views)