This isn't an issue directly with RobotOS.jl I think, but rather with its use of PyCall. However, I'm hoping there's some insight to be gained here, and maybe things that can be done to mitigate on the RobotOS/my own side.
What I'm seeing when profiling my ros project is that almost all of the time of my application is split between:
- the async callback in pubsub.jl line 59. A significant fraction of this is spent in conversions implemented in PyCall that appear to be inherently type unstable (e.g.
py2array). And much of that time is spent on pyerr_check.
- Side note, but maybe worth mentioning: I've noticed that the longer the time between two calls to
rossleep/the subscriber callbacks, the more time is spent processing these pyerrors. Maybe there is a list of them that accumulates over time and is cleared after the yield? Not sure if this is related...
- a type unstable call to
convert stemming from gentypes.jl line 489, which leads to a type unstable call to NpyArray from PyCall
- a type unstable call to
ismutable that stems from gentypes line 507, and which is seemingly required for deepcopy and any array allocations
I'm wondering if you're aware of the bottlenecks above, and if you have any experience dealing with them. I'm hoping there is something to be done here, since the 3 items above account for almost my entire computation budget 😅
This isn't an issue directly with RobotOS.jl I think, but rather with its use of PyCall. However, I'm hoping there's some insight to be gained here, and maybe things that can be done to mitigate on the RobotOS/my own side.
What I'm seeing when profiling my ros project is that almost all of the time of my application is split between:
py2array). And much of that time is spent onpyerr_check.rossleep/the subscriber callbacks, the more time is spent processing these pyerrors. Maybe there is a list of them that accumulates over time and is cleared after the yield? Not sure if this is related...convertstemming from gentypes.jl line 489, which leads to a type unstable call toNpyArrayfrom PyCallismutablethat stems from gentypes line 507, and which is seemingly required fordeepcopyand any array allocationsI'm wondering if you're aware of the bottlenecks above, and if you have any experience dealing with them. I'm hoping there is something to be done here, since the 3 items above account for almost my entire computation budget 😅