Extreemly slow transfer speed via .NET Connector -- fixable or architectural limitation?

[Charles Milutinovic]

I was recently performing some performance tests on MySQL with a query that returns about 17M rows x 60 columns of ints and bigints. This query was much slower than some other databases, and after some probing I believe the slow part to not be the query itself, but is actually a function of the amount of data being sent back to the client.

When running the application in a profiler, I discovered that about 60% of the time spent in the MySqlDataReader.Read() method was spent in .NET string extraction and parsing methods. This leads me to believe that the data is being communicated via text, and then parsed back into binary types, which would explain the terrible performance.

My question is basically if there is a more efficient way to transfer the data resultant from large queries to clients than MySqlCommand.ExecuteReader()/MySqlDataReader.Read(), or if there are any tunable settings that I am missing. Also, if there are not, then will every connector have this flaw (text->bin conversion being the large majority of the processing time), or is there a connector that is architected differently?