This content has been marked as final. Show 6 replies
Windows piping could be slow. It sounds like you'd be better off having the first JAR write to a file and the second one read from it. I never found pipes all that fast on Unix either. It's noteworthy that although compilers could be written to use pipes, they never are: they use temp files between the passes.
I have a JAR file that reads a specific file format and writes the data to STDOUT.
I have another JAR file that reads this data from STDIN and processes it.
. . .
I use BufferedOutputStream in the class that writes to STDOUT AND for the class that reads from STDIN.
For me the obvious question is why you are sending the data to the file system at all. Why not just pass it from the reader to the processor directly.
If the processor is reading from STDIN the data must be in text format so why not have the reader use a ByteArrayOutputStream and let the processor use that byte array as a ByteArrayInputStream.
There must be something you aren't telling us.
both STDIN and STDOUT are buffered, so data won't be available on them until the buffers are full.
It's noteworthy that although compilers could be written to use pipes, they never aregcc
Use pipes rather than temporary files for communication between the various stages of compilation.
This fails to work on some systems where the assembler is unable to read from a pipe;
but the GNU assembler has no trouble.
OK so now tell us that it's faster, and then why it's only an option, not the default.
I went into all this in great depth many years ago when I was writing production compilers, and there is really no point. Pipes are nice for plugging occasional user command chains together, but if you're even slightly interested in performance there is absolutely no way you won't use a temp file in preference.
pedron wrote:Easy way to find that out is to write two apps that do nothing but read and write and measure it.
What kind of throughput should i expect in this situation? What is fair/expected?