#python #multithreading #ctypes #python-3.2 #python-3.1
#python #многопоточность #ctypes #python-3.2 #python-3.1
Вопрос:
Я прочитал изменения в Python 3.2 и понимаю, что он значительно улучшен по сравнению с 3.1. Однако мой точно такой же код с нулевыми изменениями, выполняемый на 3.2, более чем в 10 раз медленнее, чем при запуске моего кода на 3.1.3
Python 3.2 потребовалось шесть минут, чтобы передать двоичное содержимое файла на физическое устройство, затем получить и распечатать полученные данные на экране, в то время как выполнение точно такого же сценария на том же компьютере с Python 3.1.3 занимает всего 30 секунд.
Я разработал свой код с нуля с помощью 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:Python31libqueue.py.qsize:86 46070 1.352867 4.234082 0.000092
C:Python31libqueue.py._get:225 8305 0.012457 0.017030 0.000002
C:Python31libqueue.py.get:167 8305 0.635926 1.681601 0.000202
C:Python31libqueue.py._put:221 8305 0.016156 0.020717 0.000002
C:Python31libqueue.py.put:124 8305 0.095320 1.138560 0.000137
on 3.2
name #n tsub ttot tavg
C:Python32libqueue.py.qsize:86 252168 4.987339 15.229308 0.000060
C:Python32libqueue.py._get:225 8305 0.030431 0.035152 0.000004
C:Python32libqueue.py.get:167 8305 0.303126 7.898754 0.000951
C:Python32libqueue.py._put:221 8305 0.015728 0.020928 0.000003
C:Python32libqueue.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, более чем в 30 раз хуже
Python 3.2 кажется катастрофой для моего приложения
Комментарии:
1. Вы в конечном итоге выяснили, что это такое? Это может быть регрессией в Python, кажется маловероятным, что это меняет поведение языка, но вы могли бы внимательно посмотреть, может ли это быть так.
2. В итоге я удалил Python 3.2 со всех компьютеров и переустановил 3.1.3
Ответ №1:
Нет очевидной причины, почему это должно быть. Вам нужно будет профилировать приложение, чтобы точно увидеть, на что уходит это дополнительное время.
Комментарии:
1. вывод на экран выполняется в режиме реального времени. при измерении моего кода печатается каждый блок данных, который он получил через драйвер Windows, как только данные получены. на PYthon 3.2 печать выполняется медленно до такой степени, что я могу прочитать каждый двоичный символ на экране по мере их печати. На Python 3.1.3 распечатка выполняется слишком быстро, что я ничего не могу прочитать на экране во время печати данных. Это серьезная разница в производительности, и она огромна. подумайте о 30 секундах на 3.1 и 6 минутах на 3.2. Я думал, что GIL был улучшен с 3.1 до 3.2…
2. @SCM: Ага, это очень интересно. Вам нужно профилировать приложение, чтобы точно увидеть, на что уходит это дополнительное время.
3. Я отредактировал и опубликовал профилирование yappi в моем многопоточном приложении для сравнения между Python 3.2 и Python 3.1.3. результат на удивление плохой для Python 3.2
4. @SCM: Хорошо, главный вопрос здесь в том, почему qsize вызывается в 5 раз чаще. Это основная причина потери производительности. Честно говоря, я не уверен, вообще почему он вызывается.
5. возможно, один и тот же файл .py компилируется в другой файл PyCodeObject с помощью 3.2 и 3.1.3. Я не изменял какой-либо код при запуске в обеих версиях python, поэтому я не могу придумать никакой другой причины, по которой между ними существуют различия.