2020-4-14 14:48 |
Как программист настольных программ, расскажу, почему программа зависает. Вкратце. 1) Очень много чужого кода, и если натыкаемся на ограничения, заменить или подправить — дело сложное или невозможное.
2) Даже индикатор ожидания правильно сделать непросто.
3) У нас быстрые машины, и без тестирования на слабых можем и упустить ошибку.
4) Как-то работает, можно ли лучше — нужно исследование, может, забить?
Мы зачастую ограничены стандартной библиотекой языка (встроенной в компилятор) или интерфейсным фреймворком (VCL, Qt, WinForms и прочие). Прикладные программисты обычно не опускаются до функций вроде VirtualAlloc или CreateWindow — за них всё написано, и строки, динамические массивы, деревья поиска и прочие структуры данных сидят в стандартной библиотеке, а окошки и таблички — в интерфейсном фреймворке. Ах да: под Маком нет ни VirtualAlloc, ни CreateWindow, и разработчики библиотек об этом тоже позаботились.
Фреймворков и компиляторов раз, два и обчёлся, и их выбирают в связке, под задачу. За год до того, как появились официальные сборки фреймворка под Win64, разбирался, как собрать его самостоятельно.
Стандартная библиотека не всегда оптимальна. Однажды ускорил сложное место, одновременно заменив менеджер памяти (хорошо, что в этом компиляторе он менялся) и дописав поверх собственное специализированное управление памятью — это ж надо было додуматься? То и другое по отдельности не помогало.
Если делать программу в один поток, то любое длительное действие приводит к зависанию — так уж устроена Windows. Делать живой независающий индикатор — это уже два потока, один для интерфейса и индикатора, второй для задачи. Но многопоточность — известный программистский жупел: её сложно написать правильно, и хорошо, если фреймворк помогает.
Буквально вчера аукнулись два ограничения фреймворка. Тормозит прокрутка большой таблицы (делал тесты и виновника знаю, и это не прикладной код), и как восстановить свёрнутое-развёрнутое состояние узлов большого дерева, если это дерево перестраивается с нуля. То и другое — работа с интерфейсом, и в принципе не делается в другом потоке.
Чего греха таить — компьютеры прикладных программистов, может, и не быстры в играх (видеоплата какая попало), но процессор обычно топовый, под разгоном, и без SSD никуда. Так что на этом «монстрике» добрых полгода не видел неоптимальности в интерфейсе, пока тестеры носом не ткнули.
Наконец, другие задачи или простая лень. Бывает, что подвисание и самому программисту на его неслабой машине надоедает, только «сделать правильно» потребует очень много ресурсов, и нет гарантии, что будет результат. Иногда эти ресурсы находятся: однажды сильно оптимизировал работу с ODBC, потому что ни над чем более серьёзным после нервотрёпки работать не мог, и это дало «клиента-кита».
Второй случай — получил через DirectInput список джойстиков, определить: это джойстик для Xbox или нет? Исследование показало: для Windows XP и 7 разные методы, метод 7-ки не работает на XP, метод XP тормозит на Семёрке.
Сейчас бы я послал лесом владельцев ХРюни, но это было давно, а последний браузер перестал её поддерживать в 2017.
.Подробнее читайте на zadolba.li ...