Why this type-coercion dot at WRITE FILE?

[Ben]

I ask that you please take a look at the attached zip.

I repeated what I was trying to accomplish earlier (that being, shedding the strict typedef with disconnecting).

This time I used a "to more generic" that operates on the reference to the typedef.

I think this may be what what we need.

Trying to help,

Ben

[CoastalMaineBird]

I think this may be what what we need.

I appreciate your efforts. But look at the output of the VALUE property node. I show a new buffer being created there.

It's true you're no longer doing it at the WRITE file, but you've added a new buffer at the property node. So the same problem exists, I think.

[Chienwei]

Wow I didn't know "to more generic" operation could be used to make typedef controls more genetic. (let me put this in my notebook :-)) But doesn't a property node keep the front panel items in memory and keeps an extra copy of the control in memory?

Dan

[Ben]

HI Dan and Coastal,

"But look at the output of the VALUE property node. I show a new buffer being created there."

Yes but the buffer is empty and only done once when the file is created.

This is not ideal, but I beleive it helps with the original concern ie performance while writing.

Ben

[Chienwei]

Hi Ben,

I've modified your VI a bit to compare the execution time of both methods (write directly to Write VI, and by using a property node to declare the type).

It turned out the VI would run a lot slower with a property node in the VI. I also tried using a smaller-sized datatype (the original Boolean typdef in your VI) and obtained the same results -- property nodes should not be used for performance critical programs at all.

Dan

[CoastalMaineBird]

Yes but the buffer is empty and only done once when the file is created.

In my case, that is immaterial. The create / write / close will be a single operation.

My data will contain a huge array, and THAT will be empty, but the structure will still contain 250k of clusters and stuff. Maybe that's the best I can do.

FWIW, I created a constant from your latest typedef, and used that as the DATALOG TYPE into NEW FILE. It still created a new buffer at WRITE FILE. But if I disconnect the constant from the TYPEDEF, it does not.

[CoastalMaineBird]

property nodes should not be used for performance critical programs at all.

This has been my experience as well. Getting even the value via a property node is VERY expensive, in terms of time, compared to a wire to the terminal.

[Ben]

Yes I agree that property nodes are not very fast. That is why I was trying the typecast in my early experiments.

How about using another copy of the typedef'd control (same type def, just a copy) to do the opening. This will allow you to maintain the strict linkage but since the control will just be used as a prototype there is no data required.

I will also question if there really is any data transfered in the case of the "New File". This seems like a waste of time copying the data when all the New FIle does is create a file and return a refnum.

If you look at my example, the property nodes does not carry the data used for the write. That is straight from a terminal.

It would be interesting to see the results of the three methods benchmarked side by side.

1) Straight typdef no funny stuff.
2) Disconnected typedef
3) Less specific version (using seperate control define data type).

Have fun!



Ben

[Chienwei]

Performance ranking:
(1) Constant with disconnected typedef
(2) Straight typedef no funny stuff.
(3) Less specific version (using seperate control define data type).
(4) with property node

However, I've noticed on my PC that when using a duplicated typedef as the input for DATALOG TYPE, the performance is inconsistent (sometimes it's faster than Stright typedef; sometimes it's slower than property node).

Attached is the VI that I used for the test. I've set the default values for the control so it'll be easier for you to test the VI. The indicators show a typical output from my PC.

Dan

[Chienwei]

It just brought to my mind that the files that are created from the test VI are ~38MB each, and that's almost twice of what CoastalMaineBird is writing. It takes my PC less than 2 seconds to write a file like that. I wonder how much performance improvement are you looking into, CoastalMaineBird?

Dan