If the first version if open to the public then it might be helpful to provide a link to it so people can take a look before they decide whether or not to offer. If that's not possible, at least an indication of the total number of both lines and files would be useful.
I might be able to take a look or not depending on the size of the code, but my spare time is fairly limited right now!
Note that in Python multi-threading doesn't necessarily give you a performance increase because only one thread can be running at a time (due to something called the Global Interpreter Lock or GIL). If the application is primarily IO-bound (e.g. it spends most of its time waiting to send and receive network traffic) then multi-threading can be a convenient way to make improvements. Many coders jump straight to this conclusion first, however, and fail to even consider options such as eventlet which uses non-blocking IO to allow many (not all) of the same performance benefits of multi-threaded code.
If your application is CPU-bound (i.e. it spends most of its time doing number crunching in the CPU) then multi-threading probably won't help much in Python. The multiprocessing library may help in that case, but my intuition tells me that your application is probably mostly of the IO-bound type anyway.
All that said, unless the original coder was relatively competent, there are probably a number of performance improvements that can be made even without multi-threading. It's a source of continual amazement to me how poorly some Python code performs just because people couldn't be bothered to profile and optimise their code. Often a simple change of algorithm or data structure can work wonders - can be as simple as using a
collections.deque instead of a
list, for example.
Anyway, that probably wasn't particularly useful, but you never know it might be handy for someone. (^_^)