Conceptually, you're already calling a static function, so the easy answer is to just go ahead and code them that way. A harder answer is that you probably have an underlying design flaw, such that this object is either a "misc" that you just threw a bunch of left over code into, or you are passing it a lot of state on each of those calls.
While they are all in that object, they're coupled, and you have less flexibility in refactoring the design. If you break it apart into just functions, then look at which go together, what state they are using, etc., you can move that functionality to where it belongs, either in one or more objects with discrete state, in the objects that are calling them (because it has to "borrow" their state), or as a singleton object that aggregates state.
Sometimes functions are just naturally static, they have no state aside from the parameterization, so they don't need to be part of an object. It's still better to leave them as functions rather than bound together in an object, because as your code evolves, it will be easier to migrate them.