Perfomrance issue with DVRs

[Mark_Yedinak]

Recently I modified a class which was using a single element queue (SEQ) to store data to use a DVR. The modification was necessaary because there was a chance when empty data could be returned when using the SEQ. Anyway, all that was done was to to replace a dequeue/enqueue with a DVR reference. This construct is used throughout the methods in the class. Performance was good with the SEQ but it did have the above mentioned bug. Replacing everything with the DVR as illustrated in the attached pictures.

Modified code:

Original code:

This class is used to store and manage message routes for a messaging system. After the modification the messaging system seems to loose routes as well as the performance of the system dropped significantly. This drop in perfromance is not acceptable. However I am not sure why this is not working as expected. Any thoughts would be appreciated.

[Darin.K]

Why are you timing out the dequeue of the SEQ and then ignoring the timeout output?  That will never wait more than 1 msec.  The DVR will dutifully wait as long as it takes.

[Mark_Yedinak]

The queues needed to timeout as they could not wait forever. Even with the timeout made longer there is still the bug where one of the methods could return an empty data set. The code using this should not get stuck waiting forever since all of the operations are quite fast. I could understand a small decrease in performance but what I am observing is ridiculous. Like go out an grab a byte to eat slow.

[Darin.K]

---

@Mark_Yedinak wrote:

The queues needed to timeout as they could not wait forever.

---

Sure, but why enqueue the default data value returned when it times out.

[Mark_Yedinak]

---

@Darin.K wrote:

---

@Mark_Yedinak wrote:

The queues needed to timeout as they could not wait forever.

---

Sure, but why enqueue the default data value returned when it times out.

---

True, that could be a problem. However that still does not explain why the code worked using the SEQ and basically does not when using the DVR. In fact, the DVR should be more reliable. Nothing being done in any of the class methods should take more than a few milliseconds at most. Even with the DVR dutifully waiting I should not miss messages or bringing the application down to a grinding halt.

In a simple test application the one using the SEQ takes about 1 second to complete. The same application using the DVRs takes 35 seconds to complete. This simple change should not have resulted in a 35 times reduction in performance. Also, nothing jumped out in either the profiler or the desktop execution trace to indicate what was going on.

[candidus]

IMHO Darin's post might contain the answer. If your queue times out it took longer than 1ms. You could handle "timed out" to prevent default data from being returned. On the other hand, the IPE waits until the DVR is available. You won't get default data but it might take much more time than 1ms.

[Mark_Yedinak]

OK, I have narrowed down the exact place that is causing the problem and I can repeat the behavior using queues or DVRs. It was related to the timeout however I can't figure out why this one particular method would casue the problem. As you see below this doesn't have any processing inside of it. Simply getting the currnet value results in a very long delay. The other method that may get called at the same time does not take 10 seconds or more to run. It grabs the value (which is a 1-D array) and searches it. The array contains no more than 100 items. Hardly anything that would take very long. I have been looking at the desktop execution trace to see if it gives me any clue but this is quite baffling. There really is no reason the queue/DVR should be held off for more that a few dozen milliseconds.

[candidus]

Without knowing details of your messaging system: How many VIs try to access the SEQ/DVR simultaneously? Maybe you have a bottleneck here...

Is your method VI reentrant?

[tst]

The first thing you should do is change the timeout to -1. That's what the others were getting at. If the behavior is the same, then you know the problem is not with the DVR itself, but with the interaction between the elements.

The second thing I would suggest is trying to more accurately pinpoint where the delay is. I would suggest a simple logger which logs the time (and the VI name) when you dequeue (or start running the code in the IPES) and logs when you enqueue (or come out of the IPES). This should at least really tell you where the delay is. I understand that you think you found it, but I've seen that these things can sometimes be misleading.

Incidentally, even if the array only contains 100 elements, the only thing I can tell about it is its name and that it presumably contains some strings and a cluster of numerics. In theory, it could still have something big inside it and the act of creating that copy is what takes the time, although I agree that doesn't seem likely.

[Norbert_B]

To add another question:

Are all VIs accessing the SEQ/DVR using the same priority? Or did you meddle with that as such that preemption can take place prolonging possible "priority inversions"?

Norbert