Sometimes, but only sometimes, small changes to the code can reap large rewards. As an example, if the application truely is Perl 4 code, then I believe (but could be wrong) that Perl 4 didn't support hashes. Assuming for the moment that is true -- I'll be quickly corrected if it isn't:) -- and (for example) the application does any sort of lookups into arrays of data using grep, then changing the array(s) being search linearly to hash(es) could have a dramatic effect without too much effort.

I'm not really sure I understand the reluctance to modify. You said this is because you hope to upgrade to the next version sometime in the future. If you make changes now, how does that stop you upgrading? The only reason refactoring the code (ie. not changing what the code does, but only the way it does it) would impact your upgrade, is if you discovered that the later version wasn't as efficient as your modifed version. In which case you would have very strong grounds for requesting that your changes be fed back into the latest version before you took delivery. The supplier might even thankyou for it and reduce your bill (some chance:). Their customers almost certainly would thankyou.

At the end of the day, if you change nothing, nothing will change. If you can't change the code, then you already know the other options. More memory, a faster processor, harddisks etc.

I think you already knew this though, so it begs the question, what were you hoping for?

Oh! You have already done the Monk's ritual haven't you?