Hello Mark,
NI does not make a profiling tool for LabWindows/CVI, nor do I know of any third-party ones (a third-party one is unlikely as CVI does not provide an interface for third-party plug-ins or add-on products). However, to help in tracking down memory leaks on the heap, the function CVIDynamicMemoryInfo() can be used. It will give all information CVI has regarding memory allocated/deallocated by new/delete.
Regarding your static string situation, your program/memory footprint size should only increase by the total length of all static strings in your program (including the NULL character) plus the code to perform the error checking. The code that is inserted to perform the error checking (and call the proper error functions in the true case) is blin
dly inserted (#define) in every case, and they will likely be larger than the size of your static strings. Is the total size of all of your function names really large enough to be of concern? One note is that __FILE__ will cause a new static string for each time your macros are inserted (the compiler does not go through the list of static strings to search for redundancies). As such, you might want to define one static string for each of your files (myfilename = __FILE__) and use it in your macro to gain some memory savings. If you are really worried about memory usage, you could assign a number to each function and use a mapping of some sort, but this would likely result in a minor memory savings for a major pain when debugging an error (the cost/benefit is thumbs down). I would recommend tinkering with your error macro considering the above information then watch the size of executable created (since you are observing static objects, the executable size will be a direct correla
tion). I hope this information is helpful to you.
Jeremiah Cox
National Instruments
http://www.ni.com/ask
