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

BufferCore wastes time in canTransform() creating error message that is never used #468

Open
peci1 opened this issue Jun 18, 2020 · 1 comment

Comments

@peci1
Copy link
Contributor

peci1 commented Jun 18, 2020

extrapolation_error_string

CompactFrameID parent = f.gather(cache, time, &extrapolation_error_string);

is only read when error_string is non-null:

if (error_string)
{
std::stringstream ss;
ss << extrapolation_error_string << ", when looking up transform from frame [" << lookupFrameString(source_id) << "] to frame [" << lookupFrameString(target_id) << "]";
*error_string = ss.str();
}

However, even when error_string is null, pointer to extrapolation_error_string is still passed to gather(), which means the stringstream operations are performed no matter what the value of error_string is.

And the string operations aren't exactly cheap (this is a flamegraph from a profiler, x axis is total time accumulated over all calls to the function):

Snímek obrazovky pořízený 2020-06-18 15-35-40

@peci1
Copy link
Contributor Author

peci1 commented Jun 18, 2020

Okay, this simple case is solved by #469. But there's also a great performance loss due to the error string construction in lookupTransform where you can't choose to not construct the strings. I'm just thinking about an interface that would allow to tell that the user is not interested in the error string, but just in the exception type...

ooeygui pushed a commit to ms-iot/geometry2 that referenced this issue Oct 12, 2022
Co-authored-by: Alejandro Hernández Cordero <ahcorde@gmail.com>
Co-authored-by: Chris Lalancette <clalancette@openrobotics.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant