postdeferredcall speed, the return

[crazyfwed]

Hello,

I've already posted something about PostDeferredCall some time ago (http://forums.ni.com/ni/board/message?board.id=180&view=by_date_ascending&message.id=33178#M33178) but, after some more investigations, I have not been able to solve my issue.

The issue was a different responsivness of PostDeferredCall whether the mouse was moving over the interface or not.
Playing with the performance parameters from windows (XP) have not changed anything.

I have now discovered another unexpected behavior concerning the PostDeferredCall: the time between the call of PostDeferredCall and the call of the scheduled function increases exponentialy.
This increase is noticeable after more than 3000 calls (sometimes only after 10 000 calls).
The scheduled function consists in doing some basic things (which are not time consuming) and then scheduling itself by doing a PostDeferredCall).

Moreover, the interface seems to be affected in a comparable way: when I notice a responsiveness decrease because of PostDeferredCall calls, I stop the self-scheduling of the function (thanks to something like if (boolean) PostDeferredCall(myfunc);), and I notice that button clicks are taken into account less quickly than before.

So, I believe the problem is not mine because I've checked about some possible memory leaks using CVIDynamicMemoryInfo (assuming the information given is pertinent enough).

Changing from "debug configuration" to "realease configuration" doesn't help.

If someone has ever seen something like that or has any possible explanation, that would be great.

If someone has any idea on how to avoid this issue (maybe by using something else that PostDeferredCall, a timer is not fast enough, an async timer can flood the interface), I'm interested.

I'm trying to reproduce this behavior by building a simple application which triggers this behavior, but It may be triggered only under certain circumstances.
Up to now, I don't have any proof against PostDeferredCall to explain this responsiveness decrease, but I can provide it to show the moving mouse effect.


Edit:
I forgot to mention that I'm using CVI 8.5.0

Message Edité par crazyfwed le 09-09-2008 05:14 AM

[LuisG]

Hello,

A degradation of the response time of PostDeferredCall is definitely unexpected, and I would like to investigate it. But so far, I haven't been able to reproduce the problem. I tried running a test program with 20,000 iterations, but it didn't show any slow down over time (although it does show an alternating phenomenon in the response time of consecutive calls which I can't quite explain either).

It might be that I couldn't reproduce the problem because your scenario differs from my test program in some significant ways. I'm attaching the program here.I'm hoping that you can tweak it in the direction of your real program, and so reproduce the problem. If you do, please reattach it here so that I can reproduce it myself.

Thanks

Luis

[crazyfwed]

Hello,

After some more investigations, it looks like I've been some kind wrong: there is no degradation of the response time because of PostDeferredCall.
I'm sorry for that.

In fact in some other functions used in the called function, there are several malloc (with associated free) which are the source of the response time degradation.
So, I solved this issue temporarily by avoiding repetitive malloc (using fixed-size arrays).

I have, now, another question related to malloc/free.
In general, is it a good idea to make malloc/free inside some functions when these functions are to be called several times per seconds ?

As I've never experienced this exponential deterioration under Linux (but it was absolutely not related to CVI), I'm wondering if some people have already noticed such a behavior. Maybe it is a windows-specific problem.

Thanks for any answer.

[LuisG]

Calling malloc/free can definitely have a performance impact. I would think that that could also happen in Linux, but the pattern might be different -- less obvious in some cases, maybe more obvious in others. Definitely if you keep allocating memory and holding on to it, the performance degradation will become more noticeable over time, as the amount of allocated memory increases, and therefore the memory manager has more data blocks to manage whenever it is invoked (by calling malloc or free). But even if you release each memory block before allocating the next one, there's the possibility that increased fragmentation of the free memory list can cause future allocations to become slower if, for example, it takes longer to find a free block that is large enough for the current allocation.

In general, memory allocation is one of the most common targets for optimization whenever developers set out to improve performance. Probably the most common strategy is to pre-allocate memory as much as possible. For example, if you are growing the same buffer periodically, you should grow it by big chunks at a time, rather than making minor size increments. This will reduce the number of memory increases. If, instead, you have lots of individual buffers, you might want to consider merging them together under a single memory block. Also, if you find yourself repeatedly allocating and freeing similar memory blocks, consider allocating it just once, reusing the same memory block, and then increasing its size when needed. You'll have to decide how big to make it initially, of course. But if you make it large enough, you should be able to get away with only having to increase it very rarely.

Luis