Right now, indexing a particular p4 repository appears (from looking at the process tree of a running FishEye instance) to be a serialized sequence of "p4 print" statements. However, "p4 print" is a latency and not bandwidth sensitive operation, and it almost always makes sense to perform these with some degree of parallelism. But it's necessary for FishEye to index a p4d running over a high-latency WAN.

One way to see precisely how bad things can be is to try to index a Perforce repository on a proxy on a WAN (London-->Hong Kong) link, where the proxy isn't hot:

FishEye --> Local p4p --> Remote p4d

If the p4p is cold, it looks like what's happening is that FishEye is running a bunch of "p4 print" operations in series, each of which is quite synchronous and thus latency sensitive (in our case we have more than enough bandwidth to spare). So while you get some minor speedup on a local server at the expense of thrashing your FishEye and P4 installations, you would get MASSIVE performance benefits out of parallelizing the "p4 print" operations to some extent.

This was originally raised as a comment on FE-122 due to a misunderstanding of what that issue really meant.