How is this

> […] handing that task to Sprockets instead of resolving internally […]

even remotely related to performance issues because of random routing? You're mixing two issues that have nothing in common.

1) Grandparent has performance problems on Heroku.

2) The Rails release has performance regressions (i.e. in at least some scenarios is slower).

In situation (1) you don't want to add further slowdown so (2) is a bad thing.

Grandparent doesn't even blame his Heroku performance problems on the routing issue (although it is a plausible guess). Actually effect of the routing problem can be significantly worsened if even a subset of requests are slowed down.

I'm under the impression that the Sprockets regression should not affect you in production, because your assets are precompiled.

Is that not the case?

To be honest I don't know and I wouldn't have negatively responded to a comment indicating that or questioning it. However reading the article it sounds like it is an issue resolving asset paths so may affect you even when assets are precompiled.

Performance Regressions

There are performance regressions in 3.2.13 for both view loading and asset loading. Rails 3.2.13 changed the way assets paths are resolved, handing that task to Sprockets instead of resolving internally, which seems to be the cause of the performance issues.

Actually, the performance degradation to the precompiled assets is minimal - for a typical production environment it only effects your asset compiling time as the assets are served statically from your public directory.

The asset path and sprocket performance hit doesn't seem to affect most Rails apps, they precompile their assets, so that shouldn't be a problem.

But it does slow down dev, which doesn't not suck.