Assuming the resource is not embedded within the HTML document itself (i.e. it is linked), and the resource is on the same server with the same host name, the time to retrieve the resource via absolute or relative URI should be virtually identical. An additional HTTP request will be submitted either way. If you want to split the 'virtually identical', I would lean toward the relative path being a very, very, very small amount faster, due to the smaller amount of HTML that needs parsed, the path parsing (as you mentioned) potentially being quicker (due to the string tokenizer not having to deal with the domain portion of the address/the address being shorter). The difference here is only realistic for curiosity's sake.. I can't imagine a site being optimized down to this level (although, it may establish a good rule of thumb? Relative pathing allows you to freely change the domain/path of the site without having to rewrite all of the URIs contained within..)
One thing to consider would be if the resource is not hosted on the same server, and the server of the referencing HTML document has KeepAlive enabled, another TCP connection will have to be initialized to connect to the second server (as well as a DNS query being made to resolve the other server's host name, assuming the access is not via IP address), resulting in additional overhead in comparison to multiple referenced resources on the same server (where the GET requests would be issued within the existing TCP connection).
The same would apply to a server that does not have KeepAlive enabled; a TCP connection will be initialized for each requested resource.