Skip to content
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

takes too long to start up / refresh #3

Open
dirk-thomas opened this issue Apr 24, 2017 · 4 comments
Open

takes too long to start up / refresh #3

dirk-thomas opened this issue Apr 24, 2017 · 4 comments
Labels

Comments

@dirk-thomas
Copy link
Contributor

From @tkruse on August 16, 2013 10:10

On my machine, with a reasonable number of nodes running on a remote PR2, rxloggerlevel takes about 6 seconds too start, rqt_logger_level about 12. Similarly a refresh in rxloggerlevel takes 3 secs, rqt_loggerlevel 12 again.

Since they do roughly the same, I assume that is a bug in rqt_loggerlevel. Probably you won't notice if the nodes are running locally or just a few nodes.

Copied from original issue: ros-visualization/rqt_common_plugins#147

@dirk-thomas
Copy link
Contributor Author

From @ablasdel on August 16, 2013 15:16

I'll take a look at this later today.

@dirk-thomas
Copy link
Contributor Author

From @ablasdel on August 16, 2013 18:5

This is due to the python interface to rosservice not having an "exists" speed/convenience function like the cpp implementation. For this reason rqt_logger_level is forced to iterate over the existing services on each node in existence to see if it has "set_logger_levels".
If there is an api I'm not aware of to find this more quickly in python feel free to point it out. Otherwise I am closing this
relevant apis that are in use by rx and rqt logger levels:
http://www.ros.org/doc/api/roscpp/html/classros_1_1ServiceClient.html#a3e52e37ed6cedd85d824979cc9aadc3b
http://mirror.umd.edu/roswiki/doc/diamondback/api/rosservice/html/

@dirk-thomas
Copy link
Contributor Author

Since the issue is not resolved and still a problem the ticket should not be closed.

If you don't see a way to fix it you could mark it with the milestone "untargeted" and comment why it can not be fixed earlier.

If you would really close it you should mark it with the label "wontfix".

In this specific case it might be most reasonable to figure out if that missing "exists" you mentioned is feasible to be implemented and would actually fix the prroblem.

@dirk-thomas
Copy link
Contributor Author

From @ablasdel on August 16, 2013 19:25

Then taking a step back and verifying it actually happens would be the next step. (I jumped to the possible culprits stage)
I think untargeted is correct in this case due to there being much more important issues to handle for hydro release.

@dirk-thomas dirk-thomas changed the title rqt_logger_level takes too long to start up / refresh takes too long to start up / refresh Jul 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant