hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

11

Жажда скорости

Оптимизация программ и составление эффективного кода

В этой главе:

•Почему важна эффективность кода

•Проектирование эффективного кода

•Повышение

эффективности имеющегося кода

В этой жизни есть вещи куда важнее скорости.

Махатма Ганди

Наша культура – это культура быстрого пи% тания. Не только наш обед запаздывает на сутки; наш автомобиль должен быть быст% рым, а развлечение – мгновенным. И код должен выполняться со скоростью молнии. Мне нужен результат. Здесь и немедленно.

Ирония заключается в том, что для создания быстрых программ требуется много времени.

Оптимизация – это угроза для разработки программного обеспечения, как отмечал из% вестный ученый Уильям Вульф: «Во имя эффективности (при этом часто без дости% жения желаемого результата) совершается больше преступлений, чем в силу любых других причин, включая элементарную глупость». (Wulf 72)

Оптимизация – избитая тема, по поводу ко% торой высказались уже все, и рекомендации

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								268m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 11. Жажда скоростиClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

предлагаются одни и те же. И несмотря на это, существует масса недо% работанного кода. Идея оптимизации правильна, но программисты обычно понимают ее неверно: они отвлекаются соблазном эффективно% сти, пишут плохой код, стремясь к производительности, оптимизиру% ют там, где в этом нет необходимости, или выбирают неправильные типы оптимизации.

Этими проблемами мы и займемся в данной главе. Мы по%новому взглянем на привычные вещи. Не беспокойтесь: когда речь идет об оп% тимизации, разговор оказывается непродолжительным…

Что такое оптимизация?

Оптимизация подразумевает улучшение чего%либо, усовершенствова% ние. В нашем деле она обычно означает, что «код станет выполняться быстрее», если мерить производительность программы с секундомером. Но это лишь одна сторона. У разных программ разные требования, и что «хорошо» для одной, не обязательно «хорошо» для другой. На практике оптимизация программного обеспечения может иметь разный смысл:

•Увеличение скорости выполнения программы

•Уменьшение размера исполняемого модуля

•Совершенствование качества кода

•Повышение точности результатов

•Сокращение времени запуска

•Увеличение производительности обработки данных (не обязательно связанное с ростом скорости выполнения)

•Уменьшение расходов на хранение данных (например, уменьшение размера базы данных)

Народная мудрость в отношении оптимизации суммирована Джексо% ном (M. A. Jackson) в злобных законах оптимизации:

1.Не занимайтесь ею.

2.(Только для специалистов) Пока не занимайтесь.

Иными словами, всеми силами избегайте оптимизации. Не занимайтесь ею с самого начала и задумайтесь только в конце, если окажется, что код работает недостаточно быстро. Это упрощенная точка зрения – в ка% кой%то мере верная, но способная оказаться вредной и гибельной. На са% мом деле, производительность должна приниматься во внимание с само% го начала разработки, прежде чем будет написана хоть одна строка кода.

Эффективность кода определяется рядом факторов, в число которых входят:

•Платформа, на которой исполняется код

•Конфигурация установленного продукта

•Решения по архитектуре программного пакета

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Чтоm		такое оптимизация?
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
269Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Рассказы бывалого человека

Однажды я столкнулся с тем, что написанный мною модуль ра% ботал невообразимо медленно. Я сделал профилирование и свел проблему к единственной строчке кода. Она вызывалась часто и добавляла в буфер один элемент.

Дальнейшее рассмотрение показало, что буфер (который я не пи% сал, а получил в готовом виде) расширял себя на один элемент всякий раз, когда оказывался полным! Иными словами, при каж% дом добавлении элемента осуществлялось выделение памяти, копирование памяти и освобождение памяти целого буфера. Ес% тественно, я на такое не рассчитывал.

Это пример того, как появляются неоптимальные программы: в результате роста. Никто ведь не пишет умышленно хромые про% граммы. Но при объединении компонент в более крупную систе% му легко сделать неверные предположения о скоростных свойст% вах кода и столкнуться с неприятными неожиданностями.

•Конструкция модулей на нижнем уровне

•Исторические ограничения (например, необходимость взаимодей% ствия со старыми частями системы)

•Качество каждой строки исходного кода

Некоторые из этих факторов являются основополагающими для про% граммной системы в целом, и когда программа будет написана, решать проблему повышения ее эффективности будет трудно. Обратите внима% ние на то, что отдельные строки кода играют незначительную роль в сравнении с другими факторами, определяющими производитель% ность. Проблемы производительности нужно рассматривать на каж% дом этапе разработки и решать по мере возникновения. В некотором смысле оптимизация, не будучи особо планируемым видом деятельно% сти, должна быть предметом забот на всем протяжении разработки.

Об эффективности работы программы нужно думать с самого начала – не на& дейтесь, что в конце разработки вам удастся повысить ее ценой небольших изменений.

Но не пользуйтесь этим как предлогом, чтобы писать мудреный код исходя из своих представлений о том, что работает быстро, а что нет. Интуитивные представления программистов о том, какая часть кода снижает эффективность программы, часто оказываются ошибочными независимо от накопленного опыта. Ниже мы рассмотрим некоторые практические решения этой дилеммы написания кода.

Но сначала золотое правило. Прежде чем хоть в какой%то мере зани% маться оптимизацией, вспомните следующий совет:

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								270m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 11. Жажда скоростиClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Корректность кода гораздо важнее его скорости. Что толку быстро полу& чить результат, если он неверный!

Стоит потратить больше сил и времени на обеспечение корректности кода, а не его скорости. Любая последующая оптимизация не должна нарушить правильность кода.

От чего страдает оптимальность кода?

Чтобы улучшить свой код, нужно знать, отчего он может работать мед% ленно, неоправданно расти в размере или иным образом терять качество. В дальнейшем это поможет нам предложить некоторые методы оптими% зации кода. Но сейчас полезно уяснить, с чем мы собираемся бороться.

Сложность

Неоправданная сложность губит код. Чем больше работы должен сделать код, тем медленнее он будет выполняться. Сокращение объ% ема работ или разбиение задачи на несколько более простых и ко% ротких могут значительно повысить производительность.

Косвенность

Превозносится как решение всех проблем программирования и фор% мулируется в виде известной программистской максимы: любую проблему можно решить, добавив уровень косвенности. Но косвен% ность также часто является причиной медлительности кода. Эта критика часто звучит со стороны процедурных программистов ста% рого закала в адрес современного OO%проектирования.

Повторение

Повторение обязательно снижает эффективность кода, но часто его можно избежать. Оно случается в разных формах, например, если не сохранять в буфере результаты трудоемких вычислений или вы% зовов удаленных процедур. При каждом повторно выполненном вычислении вы теряете эффективность. Повторение участков кода неоправданно увеличивает размер выполняемого модуля.

Плохой проект

Это неизбежно: плохое проектирование приводит к плохому коду. Например, если разнести далеко друг от друга связанные блоки (ска% жем, разместив их в разных модулях), то их взаимодействие замед% лится. Плохой проект может привести к возникновению фундамен% тальных, очень тонких и сложных проблем с производительностью.

Ввод/вывод

Взаимодействие программы с внешним миром – ее ввод и вывод – это известное узкое место. Если выполнение программы блокирует% ся в ожидании ввода или вывода данных (пользователем, с диска или через сеть), она неизбежно теряет в производительности.