There is some code like that, but it is a bit different than the change we just made. That code charges extra for particular resources when it detects they are being used a lot. And in that case the actual final RC cost goes up, it is not just a temporary cost. But none of those increases protected well against this particular form of attack.

We developed this as a solution after flooding a test net with as many transactions as it was possible to throw at it, all while leaving the block size at its current level (64K), which results in the worst case memory usage for pending transactions (because it constantly generates more transactions than can fit in the blocks and they build up). Such an attack isn't particularly easy to do (we had to write special versions of hived that could even manage to do it), but long term it is important to have this kind of resilience. Part of this attack is also only opened up because we are increasing the time that pending transactions can stay in memory (which will be very useful for transactions signed by multiple parties since it takes some time for each party to pass around and sign the transaction).