LabVIEW
TDMS flexibility / performance
One more:
This time on the windows disk which is an SSD. Default settings
From 38 to 55 and from 83 to 93 I had "File Write Meta" deactivated. It is indistinguishable on the SSD.
Disregard this - I just realised no file was written.
Will repeat this.
The windows SSD this time.
Got to go now. Will take a look at the vis tomorrow - have never worked with TDMS though.
Your code looks perfectly fine to me in principle. Of course I still don't know much about TDMS.
But it is apparent from your example that writing the meta data causes thre growing delay.
I read this:
http://www.ni.com/white-paper/5696/en/
I noticed only one thing in there that might depend on file size, in section 4 (unfortunately I don't know much about how the OS handles such things either):
"In the second writing iteration, none of the properties have changed, channel 1 and channel 2 still have three values each, and no additional channels are written. Therefore, this iteration will not write any meta data. The meta data from the previous segment is still assumed valid. This iteration will not create a new segment; instead, this iteration only appends the raw data to the existing segment and then updates the Next Segment Offset in the Lead In section."
If this is the case for your data I can imagine that since the writing position of the raw data and the writing position of the meta data grow ever farther apart there could be a tax on that optimization.
Obviously this is the wild guess of someone without a clue. 
Maybe rereading that white paper will help you though since you are already knowlegable in the inner workings.
If there's nothing to be corrected on your end maybe you shoul try and get a CAR from NI.
Hi Intaris,
Thanks for your question.
It is expected that the total time increases for each iteration in your VI "Bare basics TDMS write.vi". The time used by TDMS Advanced Open increases each iteration since the number of TDMS segment grows in the written .tdms file.
Time used by TDMS Advanced Synchronous is irrelative with file size. But time used by TDMS Advanced Open increases when the number of TDMS segment in file increases, which also results in the file size grows.
If you move the time sequence into the inside loop for mainly recording writing time, you can get the identical time for each iteration.
The relative diagram is as below.
Or if in your "Bare basics TDMS write.vi", use "create and replace" for TDMS Advanced Open everytime, you can also get the identical consuming time for each iteration.
Diagram can be updated as below.
If you do not want to bring opening time during TDMS writing, then please avoid frequently opening the .tdms file.
Jie Zheng
National Instruments R&D
Thanks for putting time into this.
I am puzzeled by your answer though.
First of all because testing the vi by placing the tdms open before the loop was the first timg I did. Here is the version I modified:
I did not mention it because it seemed to have no effect. I just recorded this with the vi above:
Sencond: Why would moving the timing vis inside the loop change anything?
That is unless you mean that TDMS Set Channel Information has the same effect as Open due to the number of segments (if I understood correctly that would be disastrous for intaris use case).
RANT: I just got an "Authentication mismatch" when trying to post, lost my written text and need to completely re-write my response. 
This whole thing (Which I initially thought would be a quick technical exchange) is testing my patience and nerves. I am still waiting for a technical explanation so that I can class my observations as either user error (Which I'll gladly do if someone can convince me of it - I like learning things) or a bug (which I'm currently assuming) or simply a bad design choice for TDMS (which would essentially disqualify TDMS from our application). If there's another option, I'll settle for that too if there's a believable technical explanation for it.
Regarding Open/Close:
I see Florian has already addressed the red herring which is the File Open / Close (see also "constant write timings" below). The suggestion that the open / close orutine leads to the increased write times is complete nonsense. Just benchmark it with the open / close outside the loop (As Florian did) and you'll see exactly the same increase in write times. Any further loops I'm required to jump through in search of a satisfactory technical explanation?
Regarding Create / Append:
Completely misses the point. I need to append data to the file. It's my entire use case. Every problem can be solved by suggesting to simply not have the problem.
Regarding the constant write timings:
Nope, sorry I have to call you out on this. Your assertation does not match my observations (and as such is rejected). Try increasing the history length of the chart (There are a LOT of individual writes going on) and you'll see that the individual writes also increase with time (see attached code).
I attach a modified (note : more complicated) version of the file for your consideration which shows both overall and individual write speeds. Chart history length is set to 4M points in order to get some kind of useful overview.
Hi Florian.Ludwig,
TDMS Set Channel Information is irrelative with segment number. Please valid the attached VI "Modified Example - TDMS Advanced Synchronous Write.vi". The diagram and result are as follows.
Result:
As to Bare basics TDMS write.vi, there are two iterated loop functions. After removing the inside loop, an identical result as above is achieved. Please try the attached VI "Remove inside loop - Bare basics TDMS write.vi".
Jie Zheng
National Instruments R&D
