WRT the thread, the advise that you change your diagram or rewrite sub-VIs isn't possible when dealing with built-in library VIs. I suppose I could write my own "DAQmx Flatten Channel String With Correct Data Types.vi" but that's a lot of work doubling for minimal gain. NI shouldn't be throwing implicit typecasts around. In real programming, this is greatly looked down upon and tends to get your code dismissed in review.
Altenbach may be right about the performance hit, but probably isn't- conversion of datatypes is either done bitwise (you can do this for adding 16bit and 32bit integers, say) for no penalty or on a compiler or runtime-level conversion. Back to the thread, the conversion from int to double isn't "safe" (you can't represent integers exactly in floating point) and it isn't done without a buffer (0X28+0101 may be the binary for '5' in a 32bit integer, but that is not how '5' is represented in 64bit floating point). If there is a savings in performance, it's because LabVIEW is doing something automatically that's more efficient than a polymorphic typecast function, not because implicit typecasting is faster than explicitely typecasting.
Even if there is a performance hit, it's impact will be pretty minimal. You only call an instrument start function once per run, it's the part about reading/writing to instruments in the control loop you try to squeeze performance out of.
