multithreaded operation performance

[SupraSummus]

Singlethreaded sequential read (cat) is faster than multithreaded one.

ipfs version 0.4.23
creating 100MB of random data and uploading to ipfs ...
100MB of data at:
	QmUHPKSHhYmmH2MwgDPX7ittT3qqn9crg4Sj7MiZ2ydG5P
	QmZyDa3nqHvy5GqynswazaAeoKD9NXRgzfK4ovyMazguxE/data

### ipfs cat QmUHPKSHhYmmH2MwgDPX7ittT3qqn9crg4Sj7MiZ2ydG5P

real	0m0.630s
user	0m0.160s
sys	0m0.300s

### ipfs-api-mount QmZyDa3nqHvy5GqynswazaAeoKD9NXRgzfK4ovyMazguxE /tmp/tmp.IghxIO7cSd
### cat /tmp/tmp.IghxIO7cSd/data

real	0m5.382s
user	0m0.000s
sys	0m0.080s

### ipfs-api-mount --no-threads QmZyDa3nqHvy5GqynswazaAeoKD9NXRgzfK4ovyMazguxE /tmp/tmp.Crwlcv54BP
### cat /tmp/tmp.Crwlcv54BP/data

real	0m1.637s
user	0m0.000s
sys	0m0.052s

[SupraSummus]

This is probably caused by multiple concurent requests for single block/object. IPFS daemon has to handle all of them and thus performance is decreased. Solution would be to suspend concurent requests for same blocks/objects and do just one request to ipfs daemon.

[SupraSummus]

Adding locks to "sequentialize" API requests helps a bit, but there is still some inefficiency. I got no idea where it's coming from.

[jan@bubel ipfs-api-mount]$ ./benchmark.sh 100
ipfs version 0.5.1
creating 100MB of random data and uploading to ipfs ...
100MB of data at:
	QmUeXDoQ7EdbqBS1x3Zn8FhoTbjN7oVuVmnUvfGDkoW6jh
	QmWo7ZMDWNANpoz8ta9ptWN8UhXak5384HhUgkvDYqGrRb/data

### ipfs cat QmUeXDoQ7EdbqBS1x3Zn8FhoTbjN7oVuVmnUvfGDkoW6jh

real	0m0.495s
user	0m0.144s
sys	0m0.237s

### ipfs-api-mount QmWo7ZMDWNANpoz8ta9ptWN8UhXak5384HhUgkvDYqGrRb /tmp/tmp.odFkEi8IyS
### cat /tmp/tmp.odFkEi8IyS/data

real	0m2.853s
user	0m0.000s
sys	0m0.083s

### ipfs-api-mount --no-threads QmWo7ZMDWNANpoz8ta9ptWN8UhXak5384HhUgkvDYqGrRb /tmp/tmp.o9jS8vCp6i
### cat /tmp/tmp.o9jS8vCp6i/data

real	0m1.763s
user	0m0.000s
sys	0m0.053s