Although I agree with Brad that this is mostly an I/O bound process, a script can be slower that your I/O. Furthermore, you can sometimes benefit from running several instances in parallel (when you have RAID5 or similar).

Here is a java program I made, which (IMO) is faster than the equivalent perl/python script.

http://sourceforge.net/projects/snpeff/files/qseq2fastq.jar/download

To use it: cat in.qseq | java -jar qseq2fastq.jar-phred64 > out.fastq

And, as Daniel said, it can be parallelised trivially.

Author of Keio U.'s qseq2fastq here. Jeremy Leipzig is correct that this makes a nice "programming golf" problem in that we have a a bucket full of working solutions, and it's just an exercise in optimization to make it go faster. To that end, my approach does a lot better than perl and (according to OP) java. Given that generating real qseq files from an Illumina GA takes waaay longer than any format conversion tool, it might seem strange to put so much effort into this step (why not just wait another hour or two? It's a loong coffee break). But in some situations, like with simulated data, or lots of different data that we maybe didn't generate ourselves, it's worthwhile to make it go faster (I was finding myself in both of these categories, so I put some effort into making this).

We obviously can't go faster than the IO lets us (which can actually be quite fast with good caching, SSDs, or maybe even ramdisks if we're working with simulated data), so the goal is to waste as little time doing non-IO stuff as possible. If you're careful, C++ can do a pretty good job at that. In my testing, perl at least goes way slower than the limit of our disks, so there's room for a lot of improvement over perl at least.

And yes, it is trivially parallelizable. When dealing with Illumina generated qseq files, generally you have a huge directory of files 1 per tile (there can be like 120+ tiles) per lane per paired-end (about 1680 total for a full PE run), that most of that time we'd like to merge into at most 1 or 2 files per lane. I run 1 thread per output file (theoretically if you had a magically fast way of merging files you might run 1 thread per input file, but that seems a little crazy). For applications like Velvet, I find this level of parallelism to be very handy, because we can do things like filtering on paired-ends considered as pairs while converting (ie. get a "velvet shuffled file" (pair-ends muxed) where both pair members pass an arbitrary filter).

I'm sure it could go even faster with some more tweaking, but for now I'm happy with it. And it's readable enough that it's fairly easy to add custom filters or wrap into some other code.

I have to say I have been toying with this idea for a while (but of course doing nothing about it).

This is obviously a task that can be parallelised trivially (I get more than 1 qseq file per experiment, so I assume you all do too!)

Any conversion program could be fed to GNU Parallel - all the qseq->fastq converters I've seen are single threaded.

You could do worse than splitting the load across a few cores and concatenating the results sensibly afterwards.

Sorry, no proof of principle, just thoughts :)