LabVIEW can handle this, if you do it correctly.
1. If you aren't already, utilize the producer/consumer data design pattern. It should be a template that shipped with LabVIEW. This will allow you to take data continuously because your data processing/saving routines take place in a seperate thread. If saving the data takes longer than reading the data, LabVIEW will just keep the queue size growing with new data and hopefully you won't run out of system memory.
2. Write you data in "chunks". If you expect to write to the disk every data point as soon as it is available then that will probably be very taxing on performance because of the excessive amount of "read/write" header information going to your disk controller and other things. It is better to save 1000 samples at a time, for instance. That way you are "hitting" your disk 10 times a second instead of 1000 times a second.
3. ASCII files are very large, but I too tend to use them because of their convienance. If you think about it, one 32-bit value may be "12332.0123" which in ascii is more like 80-bits (1 byte per character, 8 bits per byte, 10 characters is 80 bits which is more than twice the amount if stored as a 32-bit floating point number). So it makes sense that if you have performance problems (even after applying 1 and 2) that you write to a binary file. Then you can easily write a program that reads the binary file and writes a text file.
4. If your computer has enough memory, you could store everything in memory and save it to a file at the end of data collecting. You would need to add more checks and stuff if you were writing this LabVIEW application for someone else.
