Python 3.2 очень медленный по сравнению с Python 3.1.x - PullRequest
1 голос
/ 22 апреля 2011

Я прочитал изменения в Python 3.2 и понял, что он значительно улучшился по сравнению с 3.1.Однако мой точно такой же код с нулевой модификацией, работающей на 3.2, более чем в 10 раз медленнее, чем когда я запускаю свой код на 3.1.3

Python 3.2 потребовалось шесть минут для передачи двоичного содержимого файла на физическийЗатем устройство получает и распечатывает полученные данные на экране, когда выполнение одного и того же сценария на том же ПК занимает всего 30 секунд для выполнения с Python 3.1.3.

Я разработал свой код с нуля с Python 3.1.2 и20% моего кода используют ctypes для выполнения транзакций через драйвер Windows с устройством USB / PCI, поэтому я не думаю, что это снижение производительности имеет какое-либо отношение к обратной совместимости.В моем приложении я создаю четыре экземпляра потоков. Подклассы потоков, каждый из которых связан с одним устройством PCI или USB в системе.Я подозреваю, что производительность ctypes 3.2 стала хуже, чем когда-либо, или есть еще что-то для многопоточности. Мне нужно поиграть, чтобы получить именно такую ​​многопоточность, какую я хочу.Буду очень признателен, если кто-нибудь сможет затенить для меня несколько лампочек

========================================

больше диагноза

Я уменьшил количество данных, которые будут отправлены и получены

python 3.1.3 тратит 3 секунды на комет, как показано в этомснимок экрана монитора системных ресурсов http://img62.imageshack.us/img62/5313/python313.png

python 3.2 занимает около 1 минуты для завершения, как показано на этом снимке экрана монитора системных ресурсов http://img197.imageshack.us/img197/8366/python32.png

Мой компьютер представляет собой одноядерный процессор Intel P4 с 2 ГБОЗУ, поэтому я думаю, что мы можем исключить коэффициент GIL для многоядерных процессоров.

Я использовал yappi для профилирования нескольких прогонов, чтобы усреднить результаты производительности как на 3.1.3, так и на 3.2.Я вижу, что многопоточность и ctypes плохо выполняются в Python 3.2.

Это доступ к потокобезопасной очереди, предоставляемой стандартным двоичным файлом Windows пакета python

on 3.1.3
name                                 #n       tsub       ttot       tavg
C:\Python31\lib\queue.py.qsize:86    46070    1.352867   4.234082   0.000092
C:\Python31\lib\queue.py._get:225    8305     0.012457   0.017030   0.000002
C:\Python31\lib\queue.py.get:167     8305     0.635926   1.681601   0.000202
C:\Python31\lib\queue.py._put:221    8305     0.016156   0.020717   0.000002
C:\Python31\lib\queue.py.put:124     8305     0.095320   1.138560   0.000137

on 3.2
name                                 #n       tsub       ttot       tavg
C:\Python32\lib\queue.py.qsize:86    252168   4.987339   15.229308  0.000060
C:\Python32\lib\queue.py._get:225    8305     0.030431   0.035152   0.000004
C:\Python32\lib\queue.py.get:167     8305     0.303126   7.898754   0.000951
C:\Python32\lib\queue.py._put:221    8305     0.015728   0.020928   0.000003
C:\Python32\lib\queue.py.put:124     8305     0.143086   0.431970   0.000052

Потоковая производительность просто безумно плохана Python 3.2

другой пример.эта функция просто вызывает API в USB-драйвере Windows через модуль ctypes и запрашивает 16 бит данных с USB-устройства

on 3.1.3
name                                 #n       tsub       ttot       tavg
..ckUSBInterface.py.read_register:14 1        0.000421   0.000431   0.000431
on 3.2
name                                 #n       tsub       ttot       tavg
..ckUSBInterface.py.read_register:14 1        0.015637   0.015651   0.015651

, как вы можете видеть, на Python 3.2 * 1031 время, которое требуется, в 30 раз хуже*

Python 3.2 выглядит катастрофой для моего приложения

1 Ответ

2 голосов
/ 22 апреля 2011

Нет очевидных причин, почему это должно быть.Вам нужно будет профилировать приложение, чтобы точно узнать, что занимает это дополнительное время.

...