Join GitHub today
Pathname usage causes significant performance degredation #506
Ruby's Pathname module is notoriously slow, and Sprockets makes pretty heavy use of it, which imposes a pretty hefty performance penalty when doing asset resolution and compilation.
I've been tinkering with a Pathname monkeypatch in an attempt to improve Sprockets' performance. I realize that this is more of a stdlib concern than it is a Sprockets concern, but Sprockets could realize some immediate performance gains by reducing or eliminating Pathname usage.
I'm testing this via Guard with
I'm comparing this against a more direct Sass invocation, via:
Pathname usage on the Sprockets codepath (unpatched):
Pathname usage on the Sprockets codepath (patched):
And Pathname usage on the more direct codepath:
The patch I'm working with is pretty straightforward - I'm just patching
And some quick numbers:
It should be pretty obvious that leaning on Pathname so hard is causing some pretty measurable performance degradation. It may be worth moving to File methods or even just custom high-performance helpers if at all possible.
referenced this issue
Dec 1, 2013
Thats basically why I'd like to use Pathname. I'd really like to avoid baking in windows specific conditions into sprockets since I'd rather now spend any extra time debugging those issues.
Unless you want to volunteer to look into any windows issue that are opened on sprockets and help maintain that code path?
It would be just a couple of extra lines in my patch to properly support Windows; I just didn't since I'm developing and deploying on Linux.
I think I could build a Pathname facsimile (perhaps a separate library?) that would be significantly faster; it would only need to implement the common functionality that Sprockets uses, and would work properly across platforms. Would there be interest in that?
This was referenced
Apr 19, 2014
Make sure you nuke your tmp/cache between tests. When the cache is stale (ie, during active development), there are some sticky spots that don't involve hike. This is particularly relevant in light of #507 / 655f129 which will mean that Sass will not be able to leverage the cache properly.
In Sprockets in particular, the two outstanding non-hike spots are:
Sass's file importer spams the everliving crap out of Pathname methods, as well, so I need to open a PR there. They are bypassed with a fresh cache, though.