A good start would be to review your test cases and prioritise them. The ones that cover the most important functionality aren't always the best choice to automate but they do at least represent the place the company will want you to focus. One cannot test everything and one certainly can't automate all the things.
If your company is totally new to test automation it may be worth bringing in a trainer or consultant to lead this work. It's a significant investment and it's easy to get it wrong and waste a lot of time.
Writing test automation is not like writing applications, performance is less important than accuracy and clarity of code or purpose. Avoid complexity , avoid fancy syntax , avoid parallel or threaded operations unless the AOT requires it.
You shouldn't try to fix the code or survive errors it's important to report them with all the details.
Try to avoid compiled languages for writing tests , they will slow you down compared to interpreted languages that have interactive shells. These can be very powerful ways to do exploritory testing to find the paths through the code , it's then trivial to change them into tests.
Create a test repository to store the tests and try to create a packaged installer so that you can reduce setup issues.