Given the context (discussing your code with your professor) you could opt to support your assertions, and just start your sentence with "I'm sorry but..." and top it off with "that's what my tests showed anyway".
Something along the lines of:
I'm sorry, but I've tested both versions. Mine outperformed what we had so far by n%. Of course, if you see anything wrong with my method of testing, I'm open to suggestions.
This phrasing still boils down to your saying: My code is, I think, more performant (which, incidentally, is perfectly fine: not too informal and not cocky at all), and shifts the topic of the discussion to how to better test performance. The latter is a classic debating trick: by changing the subject, if the opposing party then focussses on the new topic, too, will make it seem as though your initial statement (of your code being the better approach) is agreed upon.
I am a developer, and I've had these which code is best discussions more than I care to mention. I found that shifting the topic to how code is tested avoids those rage-filled-foam-at-the-mouth shouting matches quite well. If my code comes under scrutiny, I don't take offence, even if I felt my code was the better option. I was always able and prepared to defend my work, by suggesting using stuff like unexpected input, sudden loss of network connection, stack overflow and the chances of infinite recursion or data corruption.
Since you're talking to a professor, I take it you're still learning to code: TMTOWTDI (There's More Than One Way To Do It) is something to keep in mind. Give the same challenge to 10 programmers, and you'll see anywhere from 5 to 10 different approaches come back. The best code doesn't exist. It's always the best code in this case, so discussing various approaches is as much a part of programming as testing, flowcharts, debugging, refactoring and writing the actual code.
It's often said that programmers only spend 20% of their time actually programming. So if you don't feel confident challenging existing code, I'd suggest, without wanting to be arrogant or patronizing, you go ahead and dace that "fear" head on. Challenge the code. The worst that can happen is you get an edgy response, briefly pointing out one or two things you've overlooked. That's not bad: that's how you learn.
The best that can happen is that your professor says: "Well, you know what: You're right, I didn't see that", which is a nice thing to hear.
What I'm saying is: Sod the fear of sounding cocky, you have nothing to lose and everything to gain.