Hmm.. I think you're overestimating how much of a performance hit `which` is. Every time you execute a binary (like "ls" or "rm" or "python"), which happens all the time, it has to look through all the entries in the path. That operation in Unix is very very fast, and almost always cached.

In the worst case, if `setfattr` isn't found in the path -- and it checks all the path entries -- it's still super fast:
```
$ time which nonexistant-binary
which: no nonexistant-binary in (/home/epi/.rvm/gems/ruby-2.0.0-p247/bin:/home/epi/.rvm/gems/ruby-2.0.0-p247@global/bin:/home/epi/.rvm/rubies/ruby-2.0.0-p247/bin:/home/epi/.rvm/bin:/home/epi/bin:/usr/scripts:/usr/scripts:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/java/bin:/opt/java/db/bin:/opt/java/jre/bin:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/epi/.gem/bin:/home/epi/.cabal/bin:/home/epi/.gem/bin)

real  0m0.002s
user  0m0.000s
sys 0m0.000s
```

This is dwarfed by Python's startup time:
```
$ time python -c 'print("yay")'
yay

real  0m0.066s
user  0m0.050s
sys 0m0.013s
```

Python itself has to search 236 files when it starts up:
```
$ strace python -c 'print("yay")' |& grep stat | wc -l
236
```

While `which`, in the worst case, only has to look at 20:
```
$ strace which nonexistant-binary |& grep stat | wc -l
20
```

Not to mention how long it takes to run a `youtube-dl -g`:
```
$ time youtube-dl -g http://www.youtube.com/watch?v=3MihqGJ4PkY
http://r1---sn-gvbxgn-tt1l.googlevideo.com/videoplayback?ipbits=0&ratebypass=yes&gcr=ca&ip=99.232.109.246&key=yt5&source=youtube&ms=au&upn=foQBHJ9HAIU&id=dcc8a1a862783e46&mv=m&mt=1383494955&sparams=gcr%2Cid%2Cip%2Cipbits%2Citag%2Cratebypass%2Csource%2Cupn%2Cexpire&expire=1383520425&sver=3&fexp=939913%2C906942%2C932212%2C902561%2C916623%2C924616%2C907231%2C907240&itag=18&signature=C789F0BAD0998641237851E5DBFD4D954AA3F9C1.60F92C4C5DFA31DF2BA3B6D3B7D207BF3A3E823F

real  0m2.514s
user  0m0.597s
sys 0m0.040s
```

We really don't need to worry about performance of `which`. :)

I think putting `write_xattr` in utils.py makes the codebase cleaner too. The alternative of putting it all into a postprocessor might be messy.

Plus, who knows, maybe someone might want to use the `write_xattr` function in their own scripts. :)