“Efficiency,” most of the time, is not a major consideration.   “Clarity” always is.   If your subroutine breakdown as it stands right now is clear to you and more-or-less matches how you (and those who will follow you) “naturally think of” the task that the program is to solve, then I would not be overly concerned about repetition of source statements.   (Especially if the reasonable possibility exists that, someday, as the program is maintained over the coming years, the repeated statements might naturally diverge.)

While it is academically interesting to “spin-off common code into common subroutines,” this can lead to coupling of what are unrelated concerns.   If a particular piece of code is something that you think of as being truly common to several routines, and more-or-less “irrelevant” or “beside the point” to them, then spinning them off might improve clarity.

Another good idea would be to ask some of your co-workers to contribute a little bit of peer-review:   “Is this way of writing this logic clear to you?   Do you have any suggestions?”