raed lines from text file execution speed is unreasonable

[JTAG]

hello all,

I need to read  text file (1.4M), and scan all the file line and get some info (string,number ect..) from the line.

the program doing that but  the execution speed is unreasonable is take abut 30sec to do that while in VB.net it's take only

1~2sec???? can some one help me!!!!!

i'm using Labview 7.0;

my code goes like this:

open file-->read file-->while loop-->pick a line [the iteration in the while loop is connected to line index]--> get the info from output string.

Regards,

eyal.

[shoneill]

Either post your code or a picture of it, otherwise we can't really see what exactly is going on.

30 seconds is far too long.  There must be something going on which is wrong.

Hope this helps

Shane.

[tst]

LV shouldn't have a problem to do this in less than a second. I suggest you post your code (there is an attachment field under the Submit button), so we can see where the problem is.

[JTAG]

Message Edited by Support on 09-15-2005 10:50 AM

[GerdW]

Hello,

first I would do this:
1st) change all the different "Test Name", Total tested, Pass test, fail test into arrays.
2nd) in every case you check the type of test (a1, f1, etc). Do this testing outside the case, use an array to find the correct case and use the found index to index the arrays from point 1! (see attachment)

Remember: if things are the same in each case do them outside the case (same applies to loops).

[JTAG]

hello,

first thanks for your answer.

but still it's to slow. i have try to disable the for loop and look only to t3count subvi, and it's still take long long long time to do that.

i dont know what do to else. do you have any ide?......

regards

eyal.

[JeanPierre]

Use spreadsheet string to array to transform each line of the file into an array element. Index the array in a for loop. I think that pick line is inefficient because it must parse the whole file to count lines to locate the desired line number. With spreadsheet string to array the parsing is done once.

[altenbach]

Gerd's suggestions are good. Reading the file is very fast, now convert it to a array of strings, one element/line. Replace the big while loop with an autoindexing FOR loop. One of the problems are probably the 60+ instances of the reentrant pt-by-pt increment, this seems like overkill! Use a few shift registers instead!

[altenbach]

OK, I spent about 60 seconds improving the VI and it is now under 1 second execution time on your test file.

As JPD already mentioned, pick line is not useful for large strings and high line counts, because for each pick operation with a high number, it has to search the string all the way from from the beginning counting line feeds, over and over again. As you can see, your VI slows progressively the higher N is.

Simply replacing this with a "scan strings for tokens" speeds everything to a blink (see attached, LabVIEW 7.0), because the search continues at the last position.

I have not bothered correcting the rest of the code, but I am sure it could be dramatically simplified. There is a lot if unecessary and duplicate stuff. Good luck!

Message Edited by altenbach on 07-20-2005 03:41 PM

[altenbach]

OK, I simplified the rest a little bit and it runs now even faster (~100ms for you test file).

There are many ways to do this, and I have choosen an array of clusters to contain the result because it keeps the code simple and readable. I am sure many improvements are still possible. (See attached, LabVIEW 7.0). I am sure the speed could be improved further at the cost of more complex code.

Let me know if anything seem confusing to you and I'll explain.

Since it is so fast, it does not make sense to update the results display as you go. If you need that, (e.g. for processing MUCH larger files), simply place the indicators back inside the loop. There is still a lot of redundancy, e.g. A test cannot PASS and FAIL at the same time, so why do we need to keep track of both? Anything that is not a PASS is automatically a FAIL, right? 🙂

(In any case, if your VB program really takes 1-2 seconds, this suddenly seems pretty slow compared to LabVIEW ;))