C++, OpenCV, & Kinect: Processing speed goes down -
i use c++ (visual studio 2015) , opencv (ver 3.2.0) process data sent kinect v1. c++ program has no problem when starts debugging first time. after stops debugging , re-start debugging, however, gets slow.
i suspecting program closes without releasing memory (i.e., memory leak). aware of need use delete
function release memory if use new
function. didn't use new
function in c++ program (i neither used malloc()
function, equivalent new
function in c programs).
for opencv, use destroyallwindows
function @ end of program. kinect v1, use nuishutdown()
, release()
, , closehandle()
functions @ end of program.
is there else need release memory (e.g., releasing memory associated mat
in opencv)? or else causing decrease in processing speed?
i'd appreciate help. thanks.
after first run disconnect kinect reconnect , try second run.
if goes problem stuck thread. device access handled separate threads , usb can stuck (in case of error or sync problem between accessing form host , expecting on device side) until disconnect device (not sure kinect driver using jungo version nuishutdown()
infers have problem). can check task manager before disconnection if there not stuck processes left after first run.
to remedy need find out doing wrong during access. be:
wrong usb port
use side not front slots.
invalid usb transfer request
device waiting specific set of commands or stream , waits until not receive blocks other things. using unsupported commands or reading in wrong times or sizes of packets can cause this.
usb communication out of sync
pc host can timeout in case not have enough cpu power while critical operation processed (or have opened many apps on background).
this can caused wrong gfx driver suspect using rendering ... intel hd graphics can generate such problems ease on notebooks. try disable rendering in app or @ least limit rendering opengl 1.0 see if speed same in between runs. if case whole desktop flickers or not repainting parts of apps ... , animations sluggish.
another problem might debugger. if without debugger problem , can not solve it. debugging while accessing io can cause sync , timeout problems usb.
to check memory leaks can see how free memory got before 1st run , compare values after 1st,2nd,3th .. runs if value lowers got stuck somewhere. after app close memory belonging app freed os if forget delete
not matter unless thread still running ...
some usb drivers based on libusb encountered got problem handle leaks. behaves differently ... runs fine until there no free handles. after os non functional can not open window,app, ... until app closed.
[edit1] front usb slots
front slots connected motherboard relatively long cable (usually flat , not shielded) more susceptible noise. located around hdd , above high frequency parts of motherboard induce usb feed. degrades quality of usb signal causing much bigger rejection rate hence lowering sync capability , overall usable bandwidth.
if compare backside usb ports have no cables connected directly in pcb short , shielded paths connection quality much better.
so if use device demanding high bandwith or synchronism front ports bad choice.
Comments
Post a Comment