gzip - performance difference - bash

Question

I've a program writing some ASCII-output to a named pipe (fifo). I'm trying to measure the throughput of several compression-tools. Therefore I'm using the following statement:
cat fifo | gzip -c -1 | pv -b -t -r -a > file.gz
And also:
cat file | gzip -c -1 | pv -b -t -r -a > file.gz
My question is why is the average throughput from reading the file directly so much higher than reading from a named pipe. The program has an average throughput of 80MB/s when writing unzipped data to disk, so I do not think this is the bottleneck.
Gzip has an average throughput of 5 MB/s when reading from file and about 2 - 2,5 MB/s when reading the output of the program from the named pipe. Other tools even slow down much more (e.g. ltop: file = 9 MB/s; pipe = 3 MB/s).I tried buffering the output to 4K and 16K blocks before piping it to gzip but nothing changed.
So what can I possible do wrong when reading from the named pipe?
Thank in advance
PS: The program used to reproduce the behaviour:
#include <stdlib.h>
#include <stdio.h>
#include <iostream>
#define SIZE 986
using namespace std;
int main(int argc, char **argv) {
char line[SIZE];
size_t size = 0;
FILE *f = fopen(argv[1], "w");
if (f == NULL) {
perror("Could not open pipe");
exit(EXIT_FAILURE);
}
cout << "Pipe initialized.\n";
//read from the file line by line
while ((size = fread(&line, 1, SIZE, stdin))) {
fwrite(&line, 1, size, f);
}
return EXIT_SUCCESS;
}

Answer 1

Probably not the fifo is slow, but the script what producing the data.
Simple tests on my system.
In one terminal fill's the pipe
mkfifo pipe
seq 10000000 > pipe
and on the second terminal simply read it into the /dev/null
time cat pipe >/dev/null
real 0m6.382s
user 0m0.015s
sys 0m0.204s
Now the "from file" test
seq 10000000 > file
time cat file >/dev/null
real 0m0.047s
user 0m0.002s
sys 0m0.044s
more than 100 times faster!!!
But try:
time seq 10000000 > /dev/null
real 0m6.875s
user 0m6.365s
sys 0m0.026s
SLOW, the same time as "reading from pipe". So, not the "pipe is slow" but the command what producing the data.
Proof, on one terminal fill the pipe from the file
cat file > pipe
on the second terminal, read the pipe
time cat pipe >/dev/null
real 0m0.199s
user 0m0.011s
sys 0m0.124s
same fast as the pure time cat file >/dev/null