Description:
Hi, I have written an excellent test case in C# Express that shows delay on simple data
reader request to be twice as high.  The example uses the MySQL 'worlds' sample database
which has been exposed on my home machine.

How to repeat:
1. Load project attached
2. Start and ensure output window is visible
3. Press first button (for no compression)
4. Press second button (for compression)

RESULT debug info in output window which was derrived from stopwatch timer shows average
latgency of 175MS for no compression and average latency of 355MS when compression is
used.

slow compression project

Attachment: RemotePerformance.zip (application/x-zip-compressed, text), 75.40 KiB.

This is a continuation of Bug#27746.

Jared, yes, it's clear now due to nice test case you attached. Against my local 4.1 it
shows 3-5 times slower results... Will need some time to investigate.

Hmmm, 5.0.38 on localhost shows to be slower 1-2 times...

Bug is non-repo on localhost, therefore has to be performance issue relating to
decompression of network packets.  Can you verify and assign to Reggie as 250MS is too
much overhead for 1 GIG LAN.  I am curious why you would strip NET gzip stream for open
source(5.0.1 beta), when the connector itself is written in Microsoft .NET 2.0.

I can't seem to find enough quality time to look into this deeper...

Verified as described with test case provided by Jared.

Probably related to Bug#25151 & Bug#28204.

Jared, can you try 5.0.8 and inform me of result? Two related (in my opinion) bug reports
were closed recently.

Bug was fixed 1-June-07, but I only found snapshot for NET5.1 31-May-07.  Anyway you can
post link to 5.0.08 assembly(compiled).

Jared, you can easily compile it with VS (2005/2003) from SVN sources. I would be most
interested to hear if new version fixes your problem.

I am 100% BASIC programmer, don't even have C#.  Have download 5.1.2 released mid June
with MD5 9f412e4ddcd3ff39fa0d0cdae4949236 and results for 'use compression' were 2x
slower, so the current synopsis of this bug is still in effect.  Will attached my traces
so you can see MilliSecond delays when firing compressed reader accross network.

My results for use compression

Attachment: MyTestResults.txt (text/plain), 621 bytes.

Jared, thanks. I'll escalate this problem to c/NET team leader.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/40702

Fixed in 1.0.11, 5.1.5, and 5.2+.  This will not be fixed in 5.0 since 5.1 is currently
GA.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/40706

5.1.4 has multiple issues with System.Byte[] being returned for AES_DECRYPT & CONCAT
functions.

I will log a bug as soon as I have time.

These are not bugs.  By default, 5.1 respects the binary flags returned by the server and
the server sets the binary flags on many functions improperly.  There are two options. 
You can use the connection string option to preserve 5.0 "incorrect" behavior of not
respecting the binary flags or you can use the .GetString() method on MySqlDataReader to
get a string.

- GetString() works as you said
- Am I right to log bugs with MySQL : Server on mixed type CONCAT, AES_DECRYPT?

Jared

You can use the --column-type-info option with the 5.1 command line client to see the
actual column metadata returned for each query.  If you see some metadata that you think
is wrong then I encourage you to submit server bugs.  I think you'll see that the
connector will respect this data.

A note has been added to the 1.0.11, 5.1.5 and 5.2.0 changelog: 

Using compression in the MySQL connection with Connector/NET would be slower than using
native (uncompressed) communication.