Ну, в принципе, при ручной отрисовке можно с'экономить чуть-чуть, а можно и потерять. При этом ты скорее всего просто повторишь то, что уже сделано в библиотеке. И не факт, что сделаешь лучше (про СИЛЬНО лучше я уж вообще не говорю).
С другой стороны, для таких простых вещей мощности современных процессоров более чем достаточно, так что смысла в такой "оптимизации" просто нет.
Кстати, была интересная история. Знакомый делал домашний проект, где много математики. Там была функция, связанная с возведением в квадрат больших чисел. Фактически, она была чуть ли не центральной во всем расчете. Начали ее пытаться оптимизировать. Даже переписали полностью на асме, убрав все возможные проверки. Выиграли 1-2% по производительности (кстати, полный расчет шел порядка суток на не самом слабом на то время проце). В один день знакомый приходит и говорит, что смог убыстрить расчет на треть. Оказалось - он математически доказал, что некоторые числа можно сразу исключить из рассмотрения. Т.е. оптимизация АЛГОРИТМА дает гораздо больший эффект, чем оптимизация кода.
На эту тему могу привести еще один пример. Где то в интернете есть сайт, на котором есть разные задачки по программированию с автоматической проверкой. Была там задача вида:
"Для упорядлчивания команд по убыванию результата применялся алгоритм сотрировки пузырьком. При росте числа комманд скорость сортировки стала недостаточной. Надо реализовать новый алгоритм сотрировки, дающий такой же результат, но работающий быстрее". Там еще доп. описание условий. Привожу по памяти.
Суть как раз в том, что надо было полностью поменят алгоритм, т.к. никакие оптимизации существующего в заданные временные рамки работы не укладывались.
Короче, вывод. Не надо оптимизировать то, что и так работает достаточно хорошо. Пишешь программу, потом гоняешь ее на данных и, если где-то что-то "тормозит", то тогда, И ТОЛЬКО ТОГДА, ищешь "бутылочное горлышко" и оптимизируешь эту часть кода.
|