I worry that this slowdown would reflect badly on me and my performance.
If improving the code you find reflects badly on you, then you have a much bigger problem in your team than exactly how you raise the issues you find! OK, if it's not broken you don't have to fix it, but for genuine redundant code it's probably a good idea to simplify by removing it. Time estimates should be based on the practical reality of understanding code as you go and fixing issues you find. If you're in crisis mode and can't do that, then the answer would be "put your head down and hope for the best", but that should be rare.
Redundant code isn't the worst problem you could find, but it indicates an error in the thinking of whoever wrote it (or modified it to become redundant). Therefore it deserves at least as much attention as any other potential refactor you discover in code you visit, and perhaps more.
should I take the high road, and assume the team understands
No. You're part of the team, you don't understand, so not everyone understands. Don't assume there's a higher mystery everyone else is privy to. Much more likely, nobody would want it to be like that it and everyone else either hasn't noticed it or hasn't got around to improving it. Or you're wrong. In the latter case you'll benefit from an explanation of your mistake, in the former case someone else will benefit from dealing with it.
should I communicate that the code doesn't do much?
Depending how your team feels about code "ownership", it might be that the correct thing to do is just to fix it and (if the change doesn't speak for itself) discuss it when your changes are reviewed. Alternatively there might be someone in the team who's the obvious person to talk to about it before going ahead with a change, either the author or someone else with particular responsibility. When you do talk to someone, be it the owner or a code reviewer, all that's left is to decide what to say.
If you're comfortable shooting straight from the hip:
"This code does nothing"
"You forgot to return the result, shall I fix it?"
void function has no side-effects, what's it for?"
Naturally this might be considered rude, it really depends on your relationship with the person. So you can be more diplomatic:
"What does this code do?"
"Is the result needed anywhere or can we skip this part?"
"This looks wrong, so I'm not sure I've understood everything"
"I'm terribly sorry to trouble you, but I haven't been able to understand these few lines of code. It seems to me as if this function doesn't do anything, so I was wondering why that is. Quite likely I've misunderstood it, or I suppose it might be there to support some future direction, in which case I was wondering if I could usefully add some comments to explain what".
Naturally, the last example runs a fine line between obsequiously polite and just plain condescending. Some people sound good talking like that, others sound like sarcastic gits.
Personally, I usually go with "Is this supposed to not return anything?". I'm expecting the answer "no". It's intentionally somewhat impolite/joking, because with my current colleagues I can be, but I wouldn't accuse anyone of anything beyond an oversight. And if the answer is "yes" with a reason, then fair enough. Another common option for me is "I think this should return something". Both are things that I'd be happy to have said to me.