execution time problems using imaqTransformPixelToRealWorld()

[dummy_decoy]

using NI Vision 8.6.4, i am having great troubles with a call to imaqTransformPixelToRealWorld() followed by a call to imaqDispose().

everything is fine, but cycle after cycle, the execution time of the call is getting longer, to the point that after having processed some thousands of images, my image processing function takes 10 times the time it should to execute. i did not notice any memory leak, but i had no time to verify it and, since this call would leak only very small amounts of memory, it is hard to notice without investigating. i am calling this function about 30 times per image, converting 8 points each time. 

i never noticed this problem before installing the 8.6.1 patch, although i cannot tell if the problem was present or not. i installed the 8.6.1 patch to correct another unrelated problem, and i started to see this problem. i hoped it would have been caught and fixed with the 8.6.4 but it is not the case.

of course, this has a huge impact on the performance of my software...

can anybody confirm the problem, please ? and can someone tell me if the problem exists with the 8.6.0 version of the library ?

[Michiel_H]

Could you provide us with the code of your program? I've tried with an example and could not see any slow down or memory leak, even after + 1 hour of running and > some thousands of images.

[dummy_decoy]

thanks for the reply. i finally had some time to test a bit more thoroughly, and while making a small example program to demonstrate my problem, i stumbled on the solution...

here it is: you are right, there is no problem at all with imaqTransformPixelToRealWorld()... as long as you do not forget to dispose the returned TransformReport* ! somewhere in my program, i forgot to dispose of one of my reports. when reports are piling up in memory, allocation and deallocation of objects from the vision library takes more and more time.

now, i am not sure i understand why having a memory leak has such a huge impact on execution performances. after 1000 leaks, the transformation jumps from 1.9 ms to 20ms. this makes 20µs for each undisposed object, and a 10 time increase in processing time. it seems the allocation strategy of the vision library is not scaling well...

[jr_2005]

It may have been a Windows issue. As more demands are made for system memory, Windows has to start swapping virtual memory to/from the hard drive page file and that obviously takes a lot more time. This is a common cause of programs slowly grinding to a halt.

JR

[dummy_decoy]

it is not the case here. TransformReport is a small structure, only containing the coordinates of the points transformed plus 2 or 3 flags and indicators. i reproduced the problem with a very small software, and the leak mentionned above is of about 100 bytes by iteration, thus a memory leak of about 100KB after 1000 iterations, which is very small. that's why i did only notice a "time" leak and not a memory leak in my first post.