One thing to consider is that while making the i/o "go faster" could reduce run time, doing significantly less i/o will usually provide more improvement. If there is some monster process that does billions of i/o and by using a better approach the i/o is cut to only millions, the process becomes a non-issue. With this much i/o reduction, the cpu usage would also be cut drastically.
Your situation sounds very much like a conversion task i was asked to look into several years ago. The Customer Service system was being completely re-designed and re-written (changing database software in addition to the logical redesign). The direction had been chosen to use "common edit/process subroutines" for all of the online and batch input processes of the new Production system.
Someone decided that the conversion process would use the same common subroutines. The "main" conversion program called many subprograms to provide various editing/updating. In small tests everything ran well. When the first full-volume conversion test was run over a weekend it was discovered/estimated that the full conversion might run over 4 days - nonstop. This was when i was asked to participate. . .
Many of the common subroutines performed very similar functions, but not exactly the same, so there was at least double the overhead. In order to be "fresh" each subroutine was loaded form the library for each iteration Many validations were performed against various validation tables - multiple times. And on and on and on. . .
Long story short, by removing most of the subroutine calls/loads, combining similar functions, loading reference tables into the main module, creating files to load rather than directly inserting each row, etc, the runtime was reduced to under 6 hours. . .
Unfortunately, this was not a magic bullet to accomplish major resource reduction with almost no work. It was considerable work to redo the process and an even bigger issue to convince the management that the "common routines" would not be used by the conversion process.
Hope this helps,