search

phrack / ShootOFF-legacy

An open source framework to enhance laser dry fire training.
BSD 4-Clause "Original" or "Old" License
30 stars 17 forks source link

Low framerate #113

Closed banananz closed 9 years ago

banananz commented 9 years ago

Is it possible to increase the framerate in shootoff? The low framerate can cause some rapid shots to be missed.

Thanks

phrack commented 9 years ago

You can adjust the shot detection rate in the settings. If that doesn't do it for you, you might be out of luck for now. One problem with Python is that the GIL trashes multithreaded performance, which makes it a bit harder to keep everything fast. This is one of several reaons there has been some serious thought put into having 2.1 be the last version in Python, with 3.0 just being a conversion to Java.

banananz commented 9 years ago

Thanks for the reply. I thought low framerate was the culprit, but shootoff seems to detect ok when it first starts up, but lags and misses shots within a minute or so of running. Any ideas?

phrack commented 9 years ago

Are you using any training protocols or just shooting? Do you have anti-virus or back-up software that may be kicking on?

banananz commented 9 years ago

Just shooting, no targets or anything. Keeping the laser on (right after start up) Shootoff will detect the shots and show the markers as fast as the shot detection rate is set. When it starts to lag the screen will freeze on the first shot and won't update until the laser is turned off. This is happening on my laptop and tablet. Tried turning off anti-virus.

phrack commented 9 years ago

Are you getting an exception? Is there are deterministic number of shots or elapsed time before this happens, or is it seemingly random? I am starting to work on 2.1 today so the faster you can get me hints, the better.

banananz commented 9 years ago

It'll happen within a minute of starting regardless of whether shots have been fired or not. Apart from the lag, shootoff runs normally.

phrack commented 9 years ago

Whelp, that blew all of my theories out of the water. Can you use something like Process Explorer to see how much ram the python process running ShootOFF is using before then after lag?

cbdmaul commented 9 years ago

high cpu no detections

Shows nearly 100% usage of 1 cpu core (This shot only shows 19% but it was 23+ most of the time)

I got the same problem. It's not a ram usage issue (shows only 65mb in that image). The cpu seems to creep up, just enough that it can't keep up with the shot detection. We're talking only a couple percent difference. Didn't go away when I deleted all the targets.

It took probably 20 minutes before it drastically limited shot detection though

core i5-2520m (mobile) at 2.5ghz

phrack commented 9 years ago

OK, it helps a lot to know it's CPU bound. I'll take a look, but I won't assign this to a milestone given that this code base is being retired for NG (http://www.reddit.com/r/ShootOFF/comments/2zxtyp/the_whys_whats_and_hows_of_shootoff_nextgen/). If I find the cause, I'll fix it, otherwise it will be a permanent fixture of the legacy code base.

phrack commented 9 years ago

If either of you are so inclined, it would be helpful to have additional profiling data to help track this down. To gather the data run ShootOFF with:

python -m cProfile shootoff.py > profile.txt

Wait until the slowdown is bad, then close ShootOFF. You'll up with profile.txt in the current working directory. Attach that to this issue.

cbdmaul commented 9 years ago

Closed it while it was using 2x the cpu as when I had started it.

http://pastebin.com/RH7xV9dX

phrack commented 9 years ago

Interesting. I'll have to look closer to see if this can be mitigated, but most of the CPU usage is annoyingly in upstream code.

phrack commented 9 years ago

I was able to duplicate this issue on a resource constrained 6 year old laptop. After pouring through my numbers and the numbers from cbdmaul, commit ca87a063badc49ea79046526684869d6051ca8d5 seems to have done the trick. I went with a 30 minute session after this patch on my ancient laptop, and it was still just as fast as right when I started the session.

If the problem is still occuring for other people, I can only assume it's some platform specific issue in one of the libraries and that it's not worth fixing in the Python version of ShootOFF (i.e. wait for NG: https://github.com/phrack/ShootOFF-NG).