Never felt that ri is way too slow? It was never very fast, but it's become
worse as of late, since it also searches the RI documentation in your
RubyGems packages...
#! /bin/sh
cachedir=$HOME/.fri
mkdir -p $cachedir
args="$@"
cachename=$cachedir/"$(echo -- $args | md5sum | cut -d' ' -f1)"
if [ ! -e $cachename ]; then
ri -T "$@" > $cachename
fi
${PAGER-less} $cachename
It's handy for frequently consulted methods, but it doesn't make new
lookups any faster.
I've written FastRI, a DRb-enabled, fast alternative to ri.
It is *much* faster, and also allows you to access RI over DRb.
$ time ri -T Sexp
[...]
real 0m0.901s
user 0m0.752s
sys 0m0.112s
vs.
$ time fri Sexp
[...]
real 0m0.068s
user 0m0.052s
sys 0m0.000s
FastRI consists of a server (fastri-server) that provides the RI lookup
service, and the client (fri) which will locate the server automatically and
obtain the requested documentation via DRb.
Since fastri-server is running in the background, it will not have to search
all your documentation directories on each request. This makes it much faster*1 than plain old ri.
FastRI uses a Rinda Ring to allow the server to be discovered automatically
without needing to indicate the DRb URI manually. It can work also across
machines, so you could run the server in one machine and use fri in several
hosts across your network.