Does each peer prioritize inv(type=block) over inv(type=tx)? I found that when a peer receives an inv message with type=block, it will immediately request that block or that block's headers with a getdata message or getheaders message. But if the peer receives an inv message with type=tx, it won't respond immediately.  For example:

Node A  inv(tx)      Node B  |  Node A  inv(block)  Node B
        &lt;-----------         |          &lt;---------
                             |
        [delay]              |          [no delay]
                             | 
        getdata(tx)          |          getdata(block)
        -----------&gt;         |          ---------&gt;


Why is there a delay in requesting transactions but not a delay in requesting blocks? I'm guessing that relaying a transaction is less important than getting the most recent block to ensure the node is on the consensus best block chain.
I don't see any delay here.  Looking at Bitcoin Core 0.9.3's code, I also don't see any code which would cause a delay as long as the node sending the inv responded to a getdata message immediately.

Transactions and blocks are placed into to separate queues in this code:

if (!fAlreadyHave) {
    if (!fImporting &amp;&amp; !fReindex) {
        if (inv.type == MSG_BLOCK)
            AddBlockToQueue(pfrom-&gt;GetId(), inv.hash);
        else
            pfrom-&gt;AskFor(inv);


Transactions and blocks are requested in this long piece of code, which I won't paste here.

I don't see any delays here for transaction requests.  I also tested this locally, and my node always immediately replied to a new inv message (type=tx) with a getdata message requesting that transaction.

There can be a delay in relaying transactions.  For example: node A sends an inv message for a new transaction to node B.  Node B gets the transaction, but then waits before sending an inv message to node C announcing that transaction.  You can see that in this code which includes the comment, "trickle out tx inv to protect privacy".