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.
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.
07-24-2013 07:19 AM - edited 07-24-2013 07:20 AM
Dear LabVIEW experts,
I'm having a problem with read from text file. I'm trying to read only every nth line of a file for a preview with this sub vi:
I seems to work well the first time I do it. The loop takes almost no time to execute an iteration.
Then when I load the same file again with exactly the same settings one iteration takes around 50ms.
Subsequent attempts seem to always take the longer execution time.
Only when I restart the calling vi it will be quick for one file.
When executing the sub vi alone it is always quick, but I don't see how the main vi (too complex to post here) could obstruct the execution of the sub vi.
I don't have a the file opened elsewhere in the main vi, I don't use too much memory...
Right now I don't now where to look. Does anyone have an idea?
Regards
Florian
Solved! Go to Solution.
07-24-2013 09:11 AM
I don't know the LabVIEW internals here, but I would think that it is quite possible that closing a file opened for read/write access writes a new copy of the file to disk, or at least checks the file in order to make sure a new file does not have to be written.
Therefore, if your main VI calls this subVI sequentially (you don't give any information about the place of this subVI in the main VI), you are actually looking at a close (check/write) -> open operation for any time you call it, as opposed to a simple open operation the first time. If you were to open the file for simple read access (since that's all you do), it should work fast every time because there is no need to check to see if it has changed.
Cameron
07-24-2013 09:37 AM
Thanks for the answer camerond.
The sub vi is only called upon the press of a button by the user, so it is called only once at a time. It does not seem to matter how much time has passed between the calls.
Following your suggestion I set the operation of open file to read only. Now the sub vi is always slow when called from the main vi (even for the first time) but still quick when executed on its own.
Weird.
Anything else I could try?
Regards
Florian
07-24-2013 09:54 AM - edited 07-24-2013 09:55 AM
Well, seems like something in the interaction of your main VI with the subVI, please post the main VI so we can see.
Can you really manually detect 50 ms after a button press (1/20 sec)? Or are you using a datascope of some kind? For me, that would be pretty much instantaneous, but I guess my old nerves have slowed down (and I don't drink Red Bull or other supercaffeinated beverages).
Screen rewrites sometimes slow a computer's response down, could this be your problem?
Cameron
07-24-2013 10:08 AM
It's not a single delay of 50ms but each iteration of the while loop in the snippet suddenly takes 50ms instead of say 1. I took the time with timer (ms) vi. The loop may run for thousands of iterations.
Loading a 7MB file takes about 1 second on the first try. Subsequent attempts take more like half a minute!
It can't be screen writes. The FP of the sub vi is not shown.
Posting the main vi really isn't feasible - I guess I'll have to create a striped down version that still replicates this behavior.
This may take some time.
Thanks again
If anyone has suggestions that could save me trouble of decomposing my main vi completely I'd be overjoyed
Regards
Florian
07-24-2013 10:17 AM
I'd change the function slightly, instead of looping through, reading Y rows at a time, read all (-1) and decimate the array afterwards.
/Y
07-24-2013 10:42 AM
I'm most likely just displaying my ignorance here, but why do you have your file refnum wire going into a shift register on your while loop instead of a plain tunnel?
Cameron
07-24-2013 10:49 AM
@camerond wrote:
I'm most likely just displaying my ignorance here, but why do you have your file refnum wire going into a shift register on your while loop instead of a plain tunnel?
That's a common way of doing it for FOR loops, because if you don't, and the loop iterates zero times, the reference would get invalid when using plain tunnels. For WHILE loops it does not matter, because they always iterate at least once, but why not use the same everywhere and make it a habit instead needing to think about it in every sceanrio. 😉
07-24-2013 10:53 AM
@Florian.Ludwig wrote:
When executing the sub vi alone it is always quick, but I don't see how the main vi (too complex to post here) could obstruct the execution of the sub vi.
How do you measure the reading speed?
07-24-2013 11:20 AM
The only thing I can think of at the top of my head is that if your main VI is doing some sort of disk access, that would slow down this VI.
I also agree it would be better to just read the entire file and just throw away the lines you don't want.