There's no need to do this. In fact, doing so can actually hinder performance rather than help it.
Changing priority does not make anything run faster, ever
Manually setting the priority for a process simply sets the base priority for threads belonging to the process. The process may set threads to run at a higher or lower priority if desired, this is up to the programmer. However, this is done on a case-by-case basis according to the logic running on the thread in question. Threads processing I/O run at a higher priority than threads loading assets from disk in the background. If the program sets its own thread priority, the process priority has no effect.
Priority only affects one thing: which thread gets access to execution resources first
If a high priority thread and a low priority thread are both ready to run (not waiting on the system to wake them up and give them something to do) the high priority thread will be scheduled on a logical processor first, followed by the low priority thread. If two logical processors are available, both get scheduled; if only one logical processor is available, the high priority thread is scheduled and the low priority thread is placed in queue.
When multiple threads of equal priority are ready to run -- and no threads of higher priority are ready to run -- they are executed in a round-robin fashion for a set period of time. Once that period of time elapses, they get kicked off and go to the back of the line.
When a thread of higher priority becomes ready to run it will take the place of a thread of lower priority that is currently running if there's no free logical processor at that time. In other words, threads of high priority can kick out threads of low priority.
Thus, threads that are heavy on logic and computation, or are otherwise not time sensitive, are assigned low priority. Threads that are time sensitive are assigned high priority. Mucking with priorities can result in time sensitive threads not having access to the resources that they require when they need them.