-
Notifications
You must be signed in to change notification settings - Fork 799
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
memory management problem #69
Comments
What kind of computer you have? It seems that just SURF extraction take around 600/700 ms, thus triggering memory management even with an empty WM. The benchmark was done on a MacbookPro 2010 with i7 (Arrandale). As you can see on Table III of the referred paper, recall performance will vary depending on the maximum Working Memory size that can be processed online. On that laptop with 700 ms time threshold, the maximum size of WM is 221 locations. On your side the maximum size of WM seems stuck around 20 locations and processing time is already over 1 sec. |
Is it related to use debug mode rather than release mode? |
Try to build the code in Release mode instead of Debug, this generally increase a lot the performance, particularly on Windows. |
Can I ask a question?what can I do with this file |
Your results are now more similar to the paper. If you were only interested on statistics of loop closure detection, you can delete it. The database contains the graph of the created map (e.g., loop closure links). You can browse images and features saved in it with |
It's cool.Thanks for your project. |
I use the commands on the Benchmark page.But the time used at each iteration is high,I think memory management is enabled.
![1](https://cloud.githubusercontent.com/assets/9796108/14130767/e9c00e16-f667-11e5-8654-167c444c585c.png)
![3](https://cloud.githubusercontent.com/assets/9796108/14130773/f06ce022-f667-11e5-8f03-001ba1f3d0d5.png)
The text was updated successfully, but these errors were encountered: