Leaderboard

I'm pretty convinced that the Notifiers, Queues, Semaphores and such all use internally the occurrence mechanism to do their asynchronous operation. The Wait on Occurrence node is likely a more complex wrapper around the internal primitive that waits on the actual occurrence and is being used by those objects internally but there might be a fundamental implementation detail in how the OnOccurrence() function, which is what the Wait on Occurrence ultimately ends up calling, (and all those other nodes when they need to wait) in LabVIEW is implemented that takes this much of time.

That's true, if you have drivers that do not give you access to work with the generated messages, but requires you to allow them direct access to the shared resource, your solution makes sure you can still easily control the medium access. In our channel handlers we also implement a device and/or channel reservation mode - which could solve the same challenge. The device wrapper would then request a channel reservation, prior to allowing the third party driver to access the channel in it smore direct manner...(We use the device reservation function when we need to ensure that no other entity is interfering with a complex operation towards one device on the channel).

That would seem to me to be posted to the wrong thread. You probably meant to reply to the thread about the Timestring function and yes that is not as easy as changing the datatype. The manager functions are documented and can't simply change at will. Anything that was documented officially in any manual has to stay the same typewise or CIN or DLL compiled with an older version of the LabVIEW manager functions will suddenly start to misbehave when run from within a LabVIEW version with the new changed datatype and vice versa!! The only allowable change would be to create a new function CStr DateCStringU64(uInt64 secs, ConstCStr fmt); implement it and test it to do the right thing and then use it from the DateTime node. However a timestamp in LabVIEW 7 and newer is not a U64 but in fact more like a fixed point 64,64 bit value with a 64 bit signed integer that indicates the seconds and a 64 bit unsigned integer indicating the fractional seconds. So This function would better be using that datatype then. But the whole DateCString and friends function is from very old LabVIEW days. The fact that it does return a CStr rather than a LStrHandle is already an indication. And to make things even worse to make such a function actually work with the date beyond 2040 one really has to rewrite it in large parts and there is no good way to guarantee that such a rewritten function would actually really produce exactly the same string in every possible situation. That sounds to me like a lot of work to provide functionality with little to now real benefit, especially if you consider that the newer formatting functions actually do work with a much larger calendar range already, although they do not work for the entire theoretically possible range of the 128 bit LabVIEW timestamp. In fact that timestamp can cover the range of +- 8'000'000'000'000'000'000 seconds relative to January 1, 1904 GMT (something like +-250'000'000'000 years, which is way beyond the expected lifetime of our universe) with a resolution of 2^-64 or ~10^-19 seconds which is less than a tenth of an atto second. However I do believe that the least significant 32 bits of the fractional part are not used by LabVIEW at all, which still makes it having a resolution of 2^-32 or less than 10^-9 seconds or about 0.25 nano seconds.

The variant attributes is probably the fastest way for any decent sized table. Otherwise you are using the search 1D array. You can run some speed and performance testing to see which is faster for the data you have. I'd recommend you watch some of the 2016 advanced user track videos on Benchmarking and Optimization...but NI's site is a bit broken at the moment and I can't find hardly anything, but this is where the session content is, videos are a bit harder to find. http://forums.ni.com/t5/NIWeek-Session-Content/TS9524-Code-Optimization-and-Benchmarking/ta-p/3321074