Too many redirects, regardless of how they're implemented, can cause performance problems. The impact would depend on how many redirects you have, the CPU/memory/disk performance of your server, and the number of HTTP requests you receive per unit time. The only way to tell is to test.
The performance can also be affected by whether the code is placed into a server config file such as httpd.conf or conf.d where it is compiled into 'native code' on server restart and executed directly for each HTTP request, or placed into per-directory .htaccess files, where the directives are interpreted for each request -- The technical terms "compiled" versus "interpreted" being the main difference highlighted here.
In addition, the directives can be scoped in httpd.conf/conf.d using <Directory> or <Location> containers, or in .htaccess where you can put the code into .htaccess files in specific subdirectories where it will execute only for requests for URLs that resolve to the subdirectory in which it resides. This scoping approach can make a big performance difference, but at the cost of more complex maintenance.
Finally, since you'll lose all PageRank/Link popularity currently enjoyed by your old URLs, I have to add that unless you have a very good reason to change them, you shouldn't. You can simply map the old URLs to new files in any way you like. Changing URLs is usually unnecessary and should not be done lightly or merely for convenience, as pointed out by one the inventors of the Web, Tim Berners-Lee, in his paper, Cool URIs don't change [w3.org] -- A very worthwhile read.
Although you may have a compelling reason to change your URLs one last time, you can use this opportunity to design a core URL-structure that will never need to change again.