Я прочитал изменения 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 кажется катастрофой для моего приложения
Нет очевидной причины, почему это должно быть. Вам нужно будет профилировать приложение, чтобы узнать, какое именно это занимает дополнительное время.