Bug #1637 ODBC Driver slow on WindowsXP
Submitted: 23 Oct 2003 10:42 Modified: 24 Oct 2003 11:48
Reporter: jan roth Email Updates:
Status: Not a Bug Impact on me:
None 
Category:Connector / ODBC Severity:S3 (Non-critical)
Version:3.51.06 and earlier OS:Microsoft Windows (XP Prof SP1)
Assigned to: CPU Architecture:Any

[23 Oct 2003 10:42] jan roth
Description:
With Windows XP Pro SP1 select-tasks using the ODBC-driver where rather slow, no matter what GUI I used (also with mysqlcc).

When I checked the flag "don't use setlocale" in the "options" of the ODBC-Driver, speed was as expected and same as with W2K or NT 4.0.

With mysqllcc it looked like the operating system was doing some kind of sorting (high CPU-usage), until the last line was shown. A little test-tool showed the problem (look at suggested fix).

How to repeat:
Problem did not occur with W2K or NT 4.0, but only on XP Pro. 

Suggested fix:
In the options-description of the 256Bit on http://www.mysql.com/products/myodbc/manual.html#Connection_parameters 
(which is supposed to be "don't use setlocale") I found the description 
"Disable the use of extended fetch (experimental)".

So whatever that means (didn't find any other description) - this flag can solve speed-problems with the ODBC-Driver and XP Pro.

These where select-respond-results of my test-tool:

With the flag set all records in wonderfull time:
8822 records.
000 - 100 microseconds	- 8822 records

----------------------------------------------------------------------

Without the flag it took it`s time:
8822 records.
000 - 100 microseconds	- 0 records
100 - 200 microseconds	- 0 records
200 - 300 microseconds	- 8385 records
300 - 400 microseconds	- 347 records
400 - 500 microseconds	- 43 records
500 - 600 microseconds	- 19 records
600 - 700 microseconds	- 9 records
700 - 800 microseconds	- 1 records
800 - 900 microseconds	- 4 records
900 - 1000 microseconds	- 0 records
1000 - 1100 microseconds	- 0 records
1100 - 1200 microseconds	- 2 records
1200 - 1300 microseconds	- 3 records
1300 - 1400 microseconds	- 3 records
1400 - 1500 microseconds	- 2 records
1500 - 1600 microseconds	- 0 records
1600 - 1700 microseconds	- 0 records
1700 - 1800 microseconds	- 1 records
1800 - 1900 microseconds	- 0 records
1900 - 2000 microseconds	- 0 records
2000 - 2100 microseconds	- 0 records
2100 - 2200 microseconds	- 0 records
2200 - 2300 microseconds	- 0 records
2300 - 2400 microseconds	- 0 records
2400 - 2500 microseconds	- 0 records
2500 - 2600 microseconds	- 0 records
2600 - 2700 microseconds	- 0 records
2700 - 2800 microseconds	- 0 records
2800 - 2900 microseconds	- 0 records
2900 - 3000 microseconds	- 0 records
3000 - 3100 microseconds	- 0 records
3100 - 3200 microseconds	- 0 records
3200 - 3300 microseconds	- 0 records
3300 - 3400 microseconds	- 0 records
3400 - 3500 microseconds	- 0 records
3500 - 3600 microseconds	- 0 records
3600 - 3700 microseconds	- 0 records
3700 - 3800 microseconds	- 0 records
3800 - 3900 microseconds	- 0 records
3900 - 4000 microseconds	- 0 records
4000 - 4100 microseconds	- 0 records
4100 - 4200 microseconds	- 0 records
4200 - 4300 microseconds	- 1 records
4300 - 4400 microseconds	- 1 records
4400 - 4500 microseconds	- 0 records
4500 - 4600 microseconds	- 0 records
4600 - 4700 microseconds	- 0 records
4700 - 4800 microseconds	- 0 records
4800 - 4900 microseconds	- 1 records
----------------------------------------------------------------------
[24 Oct 2003 11:48] Indrek Siitan
That is a bug in Windows XP code and is acknowledged by Microsoft.
We don't know though if a fix is available yet at this moment by MS.