raed lines from text file execution speed is unreasonable ---the subvi and txt file.

[JTAG]

i dont know how to added all the part of my code!!

[ryank]

Hello,

The SubVI you posted does not have any file I/O in it, so I can't make many suggestions based upon it.  Here are a few general suggestions:

1.  When trying for speed, don't use the high level file VIs such as Write Characters to File, especially in a loop.  Use the lower level Open/Write/Close VIs because these allow you to open your file just once.

2.  Try to send as much information with each call to write as possible, writing a few characters at a time will take much longer than writing a few hundred or a few thousand at a time.

The text file you posted in your other thread is quite large, even with efficient file techniques, it's going to take a while to write it in any language.  In general, dumping that much information into a text file isn't really wise.  It's too big to really inspect visually, and it is going to take an awful long time to search.  Judging by the type of data you are logging I would suggest that you use a database.  Storage Files would also be a good choice, but unfortunately in LV 7.1 the Storage Files library is still a bit slow, so a database might be a better choice for you.

Hope that helps,

Ryan K.

[DFGray]

I would like to second ryank's comments and give you a couple of directions to pursue.

1. If you really want to use a text file, open the LVM read and write express VIs and look at how it is done there. Data is read or written in chunks to reduce disk access. Parsing or encoding is done on the chunks. There are some utility subVIs you could use to help you out. However, with large data sets, text is rarely a good option.
2. Use a file format designed for this kind of data storage. If you want speed, try HDF5. Use the primitive functions found here (Can I Edit and Create Hierarchical Data Format (HDF5) files in LabVIEW?). Get the documentation you need at the HDF website. Note that HDF5 is not easy to use. It is also not threadsafe, so make sure you only call it one place at a time. However, it is fast, self-describing, and designed from the ground up for this kind of application. There are numerous other posts on this forum discussing its use, so check them out if you decide to go this route and need more help.

Good luck. Let us know if you need more help. Just don't expect the solution to be trivial. Large, efficient data storage never is .