Python 3.2 очень медленный по сравнению с Python 3.1.x

1

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

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

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

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

больше диагопнически

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

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. Я вижу, что threading и ctypes плохо выполняются на Python 3.2.

Это доступ к потоковой безопасной очереди со стандартным двоичным двоичным файлом пакета 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 в Windows USB-драйвер через модуль 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

как вы можете видеть, время, затрачиваемое более 30 раз на Python 3.2

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

  • 0
    Вы в конечном итоге выследили, что это такое? Это может быть регрессия в Python, кажется маловероятным, что это меняет поведение языка, но вы можете внимательно посмотреть, может ли это иметь место.
  • 0
    В итоге я удалил Python 3.2 со всех машин и переустановил 3.1.3
Теги:
multithreading
ctypes
python-3.2
python-3.1

1 ответ

2

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

  • 0
    распечатка на экране в режиме реального времени. Из моего кода распечатывается каждый блок данных, полученный им через драйвер Windows, как только данные получены. на PYthon 3.2 распечатка идет медленно до такой степени, что я могу читать каждый двоичный символ на экране по мере их печати. На Python 3.1.3 распечатка выходит слишком быстро, и я ничего не могу прочитать на экране во время печати данных. Это большая разница в производительности, и она огромна. подумайте о 30 секундах на 3,1 и 6 минутах на 3,2. Я думал, что GIL был улучшен с 3,1 до 3,2 ...
  • 0
    @SCM: Ага, это очень интересно. Вам нужно профилировать приложение, чтобы увидеть, что именно занимает это дополнительное время.
Показать ещё 5 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню