Although everybody seems to believe that there is no problem with it, or no problem to worry about, I tend to disagree. Because this is about professionality.
First, as software developers we (should) strive for writing the best code we can. Even in this case, where the problem seems small, everybody will agree that this is not the best code possible - assumed "best" is defined in terms of
Second, even if the performance drop is minimal, one cannot decide without knowing the use case context whether it should be fixed sooner or later. If some piece of code is called a few thousand times in in a short time frame for some reason, every msec I can save per call will become seconds quickly. Last not least, if you are writing a library, one can't even tell less, because you don't know who is going to use it in which way and for what purpose.
Third, todays compilers do a lot of optimization work. New hardware we buy is usually faster than the old one. The average developer seems to use this as kind of an excuse. "Sure, my code is less efficient, but my brand new CPU can do it still faster than the old one, even without optimizations. So why bother?" Because the added hardware performance or the better compiler optimizations is not there for you to waste them! The idea is to get computations done quicker and with less resources, not as compensation for sloppy code.
As with everyhing, there are no fixed rules, because the mileage may vary with every piece of code and every project. But the OP just for thinking about it and asking that question he would deserve a double upvote.
PS: To qualify as an answer to the question: I'd call it "inefficient code".