TDMS API Write Only Mode

[James_McN]

You don't need to look too deep to find examples of TDMS API "memory leaks". These are not leaks but rather the TDMS API holding meta-data in memory related to the structure of the TDMS file in case you need to read from the file.

The biggest issues with this is that it makes TDMS a bad choice for RT applications where you make cause this index to build through file fragmentation however in most RT applications you are only writing. On investigating whether it would be possible to make an RT compatible API (in native LV) it appears that there is no reason for this to increase in a write only mode.

So the request is a write only API or flag in the existing API. This should prevent memory build up in loggers.

There is a design decision around whether to use a seperate API or have errors thrown if you attempt to read, I think I would be open to either but I think the error would work best to allow easy upgrade of existing applications.

[crossrulz]

Just like you get an error if you try to read from a text file that was opened with Write Only privileges.  It makes sense that TDMS should do the same.  As an extension, maybe allow for a read only mode as well.  Not sure what that would do for you, but it is a logical step when dealing with file IO in general.

[YongqingYe]

Thank you for the idea, James_McN!

We have realized this problem, especially for RT applications, the below post maybe can help:

http://digital.ni.com/public.nsf/allkb/961EDE096E98E87D862579ED0068BFF9

[James_McN]

That link is a good guide, I have some code comparing the techniques at https://decibel.ni.com/content/docs/DOC-20522 as well.

2013 is certainly improved and reduces the number of allocations although they can start to show quite significant jumps. The most effective route I have found so far is simply to not write to one file for too long.