I use a class that just extracts data from one known object, and distributes it to other known objects. No persistent configuration or such is needed in that class instance.
How should I decide whether to set up that class as a singleton, or just instantiate it every time I need it?
If the class has no state, you could consider turning it into a function or static method depending on your language.
It is sometimes considered that the singleton is an anti-pattern. Unless the problem being solved specifically requires the use of the singleton pattern, it is generally best to avoid it.
You mention that the function would have no state or other long lived requirements, so the immediate need for an object is not there either.
A free function would be best (or static function or similar given the language and target), since it carries no state and doesn't introduce any issue associated with the singleton.
If a free function is not an option, an empty object (no data members) would probably be a close enough second option.
In general, my advice when choosing a pattern is to first understand what problem the pattern seeks to solve and what the limitations and constraints of the pattern would be. Once understood, if the problem being solved falls into that pattern's problem space then that pattern would be a candidate for use.
How do you determine what these 'known objects' are - if its hard-coded in code (ie the object is a static or singleton itself) then you might as well use a static method to perform the processing, just call that as needed.
I can't see why you'd need a whole class for this process, unless those known objects are considered state internally to the class. In this case, it depends how often you need it and the cost of constructing it, it it takes a lot of effort, a singleton is probably best.
I think the answer by Niall is good and the accepted answer is correct, but wish to add a bit in the vein of using Singletons.
The Singleton pattern is a bit like Communism. It looks good on paper, but when you mix it with people things tend to fall apart.
The thing is that the Singleton pattern isn't, inherently, an anti-pattern. It's more that most (naive) implementations of it tend to skim over important aspects or cause possible issues.
For example, in C++, a globally initialized Singleton can be allocated pretty much whenever sometime before the main loop starts. Combining multiple Singletons this way means you have no idea what order they will initialize relative to each other. The order of cleanup is similarly arbitrary (but generally the reverse of the order they were initialized in). (There are SOME basic rules for this, but mostly it's left up to the nasal demons.)
Global and readily accessible objects also tend to end up veering into the realms of a God Class, which is very much an anti-pattern. Ideas like "I already have a Manager class, I'll just stick it there," are easy and the solution is quick. This is a case of Technical Debt.
A controlled Singleton managed correctly can be very useful and not cause problems, but they are a more difficult pattern to get right than people tend to expect. The worst part is that the examples out of text books tend to teach really bad habits for Singletons.
For your specific case, since you have no state and don't need to load or unload, you don't need an object. A static function or equivalent should suit your needs.
And, since I can't comment (shakes fist), I want to second Niall's point on understanding what a pattern solves and where it works. I'd also recommend researching how it works and how best to implement it, as implementing a pattern correctly is at least as important as choosing the right pattern.
