ProcessSystemEvents() slowing down

[crazyfwed]

Hello,

I'm not fighting against UI timers.

In fact UI timers and their limitation are quite interesting.

I don't mind if my 1s timer is not fired from time to time.

I don't mind if my 1ms timer is not fired 1000 times per seconds.

I don't mind if for some reason, timers are not fired because of something happening occasionnaly.

But, I don't want the interface to become less reactive over time.

Maybe I'm doing something wrong in my program, but I'm not so sure.

Right now, I'm suspecting a bad behavior related to UI timers. But that's just one hypothesis, and this is why I'm trying to get some information, because I may be doing something which triggers some CVI problem.

So, I'm willing to change my program, but I would prefer to make (big) changes only if I'm told that I'm doing something wrong.

I know that most people contributing here are not NI officials, so please don't take any comments personnally. I do appreciate all contributions.

[RobertoBozzolo]

Even if you have only the base version of CVI you can still try monitoring program behaviour, but in my opinion moving to a looping mechanism is not necessary. You may for example track down the timer firing time, knowing that eventData2 holds the time from the last call to that timer. Take a look at the modified code I am attaching.

As per the sample program slowing down if you keep the spacebar pressed, this is quite clear to me. On Windows, operating the spacebar when a button is active is equivalent to pressing Enter key or clicking on it with the mouse: it operates the button. Even if the button has no callback associated, it nevertheless sends events to the event queue and if you keep the spacebar pressed you are sending these events at the maximum rate, thus consuming system time. Even in this moment, though, the timers are firing at almost regular intervals as you can see in my code with almost the same elapsed time.

You could try monitoring the timer operation in your real application and see if the problem you are facing lies in the timer callbacks or elsewhere in the code.

[crazyfwed]

Most likely you are completly right.

I think my example is not showing what I thought.

So, by the time I'll find some explanation to what I see, I will add, as you suggested, some indicators about timer firing intervals.

Now, what I really need, is some way to accelerate the slow down I'm seeing in my real program.

Obviously, spending many time in many timers isn't the direct source of any problem (which is good and which is why I've choosen UI timers).

Thanks for your suggestion.

[RobertoBozzolo]

Well, manipulating controls at high rates, especially if several controls at a time, can have an impact on system performances.

I modified slightly your example adding two tables updated on 10ms and 250ms timers: you'll see that timer elapsed time rises over time, the effect can be observed particularly on the 10ms timer. That is to say, you can save system resources by reducing the controls updated on every timer iteration, either by not updating panels not shown or by updating controls once every <n> times (updating a numeric 100 timer per second is useless, human eyes cannot appreciate more than 3-4 times per second updates).

Generally speaking, updating the UI is a very high consuming task. A program that runs for several hours normally is not continuously monitored by the operator so UI update rate can be reduced to a minimum: you could reduce the informations always updated and add some buttons to show more details upon request.

Additionally, you said that memory allocated to the program raises over time and this is another aspect to investigate. Carefully check that you don't have memory leaks and try excluding table and graph updates to see if the memory still raises.

[crazyfwed]

Hello,

In your example, the tables are constinously growing, and this is why UI controls take more time over time.

In my program, I don't have such out-of-control controls:

- my tables don't grow over time

- my graphs only grow up to few hundreds points

- my graphs have limited number of plots (usually less than 2)

- timers update the same number of controls over time

[vinaypooja]

Please help for File operation, I've to select a text file through file select popup and convert it into binary file and store it in new file in same location please help me to write a program for it. Please anyone help me.

[RobertoBozzolo]

Hello vinaypoya, please stop from posting over and over the same question! Hijacking a thread with a totally unrelated question is a bad habit I urge you to avoid.You already opened two independent threads and received an answer here.

I see you are new to the forum, it could be a good idea to read NI Community user guidelines

[crazyfwed]

Hello,

Now I think I have something to show.

I'm attaching a very basic project which has an unexepected behavior.

You have to build it in 64 bits (both release or debug is ok).

If you lanch the program and place the mouse cursor over one control (for example the "quit" button") you have something strange:

- the loop takes more time over time

- the used memory increases over time

On two computers I have the same behavior (yet, times are a little bit different).

After 10 seconds over one control, it uses 2.8 MB

After 20 seconds over one control, it uses 3.6 MB

After 50 seconds over one control, it uses 5.4 MB

After 2 minutes and 30 seconds over one control, it uses 7.2 MB

After 9 minutes over one control, it uses 11.1 MB

This is not something normal, to me.

If you don't place the mouse over one control but still over the panel, you don't have those effects (or at least not that fast, I've not tried over long period of time).

If you run in 32 bits, you don't have those effects (or maybe over longer times).

If you add a wait in the loop, those effects appears more slowly.

So, now my questions.

Can anybody confirm this ?

Can anybody explain me what's going on ?

[Wolfgang]

Hi,

I have tried your example and cannot confirm your observation (Win 7 64): interface_dbg.exe consumes 2096 K of memory, interface.exe consumes 2084 K, in both cases no change over time, the mouse placed over the Quit button.

[crazyfwed]

Thanks for trying.

I'm running win10 64, I'm not sure I can try on win7 as they probably have been eradicated at my company.