Когда оптимизация преждевременна?
Предупреждение: [fункция] ожидает, что параметр 1 будет ресурсом, boolean задан
(более общий вариант Предупреждение: mysql_fetch_array () ожидает, что параметр 1 будет resource, boolean given )
Ресурсы - это тип в PHP (например, строки, целые числа или объекты). Ресурс является непрозрачным блобом без собственной значимой ценности. Ресурс специфичен и определен определенным набором функций или расширений PHP. Например, расширение Mysql определяет два типа ресурсов :
В модуле MySQL есть два типа ресурсов. Первый - идентификатор ссылки для подключения к базе данных, второй - ресурс, который содержит результат запроса.
Расширение cURL определяет другой два типа ресурсов :
... дескриптор cURL и мультирум cURL.
Когда
var_dumped значения выглядят так:$resource = curl_init(); var_dump($resource); resource(1) of type (curl)Это все большинство ресурсов - это числовой идентификатор (
(1)) определенного типа ((curl)).Вы переносите эти ресурсы и передаете их различным функциям, для которых такой ресурс что-то значит. Обычно эти функции выделяют определенные данные в фоновом режиме, а ресурс - это просто ссылка, которую они используют для отслеживания этих данных внутри.
«... ожидает, что параметр 1 будет ресурсом, логическим данная "ошибка, как правило, является результатом непроверенной операции, которая должна была создать ресурс, но вместо этого вернула
false. Например, функцияfopenимеет это описание:Возвращаемые значения
Возвращает ресурс указателя файла при успешном выполнении или
FALSEТаким образом, в этом коде
$fpбудет либоresource(x) of type (stream), либоfalse:$fp = fopen(...);Если вы не операция
fopenбудет успешной или неудачной и, следовательно, будет ли$fpдействительным ресурсом илиfalseи передать$fpдругой функции, которая ожидает ресурс, вы можете получить вышеуказанную ошибку:$fp = fopen(...); $data = fread($fp, 1024); Warning: fread() expects parameter 1 to be resource, boolean givenВам всегда нужно проверять возвращаемое значение функций, которые пытаются выделить ресурс , и может выйти из строя :
$fp = fopen(...); if (!$fp) { trigger_error('Failed to allocate resource'); exit; } $data = fread($fp, 1024);Связанные ошибки:
19 ответов
Don Knuth запустил грамотное программирование перемещение, потому что он полагал, что самая важная функция машинного кода должна передать намерение программиста читателю . Любая практика кодирования, которая делает Ваш код тяжелее для понимания от имени производительности, является преждевременной оптимизацией.
идиомы Certain, которые были представлены от имени оптимизации, стали столь популярными, что все понимают их , и они стали , ожидал , не преждевременный. Примеры включают
-
Используя [1 124] адресная арифметика с указателями вместо нотации массива в C, включая использование таких идиом как [1 113]
for (p = q; p < lim; p++) -
глобальные переменные Повторного переплетения к локальным переменным в Lua, поскольку в [1 114]
local table, io, string, math = table, io, string, math
Вне таких идиом, срезают путь в Вашей опасности .
Вся оптимизация преждевременна, если
-
программа А не слишком медленная (многие люди забывают эту часть).
-
Вы имеете измерение (профиль или подобный) показывающий, что оптимизация могла улучшить вещи .
(Также допустимо оптимизировать для памяти.)
Прямой ответ на вопрос:
- , Если Ваша "различная" техника делает программу тяжелее для понимания , то это - преждевременная оптимизация .
РЕДАКТИРОВАНИЕ : В ответ на комментарии использование quicksort вместо более простого алгоритма как вид вставки является другим примером [1 134] идиома, которую все понимают и ожидают . (Хотя, если Вы пишете свою собственную программу сортировки вместо того, чтобы использовать программу сортировки библиотеки, каждый надеется, что Вы имеете очень серьезное основание.)
Когда я отправил по подобному вопросу, правила оптимизации:
1) не оптимизируют
2) (только для экспертов), Оптимизируют позже
, Когда оптимизация преждевременна? Обычно.
исключение находится, возможно, в Вашем дизайне, или в хорошо инкапсулированном коде, который в большой степени используется. В прошлом я работал над некоторым строго ограниченным во времени кодом (реализация RSA), где рассмотрение ассемблера, что произведенный компилятор и удаление единственной ненужной инструкции во внутреннем цикле дал 30%-е ускорение. Но, ускорение от использования более сложных алгоритмов было порядками величины больше, чем это.
Другой вопрос спросить себя, когда оптимизация , "я делаю эквивалент оптимизации для модема на 300 бодов здесь?" . Другими словами, будет Закон Гордона Мура делать свою оптимизацию не важной в недалеком будущем. Много проблем масштабирования могут быть решены только путем броска большего количества аппаратных средств в проблему.
Наконец, что не менее важно, преждевременно оптимизировать, прежде чем программа идет слишком медленно. Если это - веб-приложение, Вы говорите о, можно выполнить его при загрузке для наблюдения, где узкие места - но вероятность - то, что у Вас будут те же проблемы масштабирования как большинство других сайтов, и те же решения будут применяться.
редактирование: Кстати, относительно связанной статьи, я подверг бы сомнению многие сделанные предположения. Во-первых это не верно, что Закон Гордона Мура прекратил работать в 90-х. Во-вторых, не очевидно, что время пользователя более ценно, чем время программиста. Большинство пользователей (по меньшей мере) отчаянно не использует каждый цикл ЦП, доступный во всяком случае, они, вероятно, ожидают сети, чтобы сделать что-то. Плюс существуют альтернативные издержки, когда время программиста отклонено от реализации чего-то еще к бритью нескольких миллисекунд от чего-то, что делает программа, в то время как пользователь разговаривает по телефону. Что-либо дольше, чем это не обычно оптимизация, это - устранение ошибки.
Путем я вижу, что это при оптимизации чего-то, не зная, сколько производительности, которую можно получить в различном сценарии, ЯВЛЯЕТСЯ преждевременной оптимизацией. Цель кода должна, действительно делая самым легким для человека читать.
Если Вы не находите необходимость в большем количестве производительности из приложения, или из-за пользователя или из-за бизнес-потребности, существует мало причины волноваться об оптимизации. Даже тогда ничего не делайте, пока Вы не представили свой код. Тогда нападите на части, которые занимают большую часть времени.
Я не думаю, что распознанные лучшие практики являются преждевременной оптимизацией. Больше в горящее время на что, если потенциальные проблемы производительности в зависимости от сценариев использования. Хороший пример: при записи недели, пытаясь оптимизировать отражение по объекту, прежде чем у Вас будет доказательство, что это - узкое место, Вы преждевременно оптимизируете.
Преждевременная оптимизация мне означает пытаться повысить эффективность Вашего кода, прежде чем у Вас будет рабочая система, и прежде чем Вы на самом деле представили его и знаете, где узкое место. Даже после этого удобочитаемость и пригодность для обслуживания должны прибыть перед оптимизацией во многих случаях.
Потребность использовать профилировщика должна быть оставлена для крайних случаев. Инженеры проекта должны знать, где узкие места производительности.
я думаю, что "преждевременная оптимизация" невероятно субъективна.
, Если я пишу некоторый код и я знаю , что я должен использовать Хеш-таблицу тогда, я сделаю это. Я не буду реализовывать его некоторым дефектным способом и затем ожидать отчета об ошибках для прибытия месяца или год спустя, когда у кого-то будет проблема с ним.
Модернизация является более дорогостоящей, чем оптимизация дизайна очевидными способами от запуска.
, Очевидно, некоторые мелочи будут пропущены в первый раз вокруг, но это редко ключевые проектные решения.
Поэтому: НЕ оптимизация дизайна является IMO запах кода в и себя.
Ответ нормандца превосходен. Так или иначе Вы обычно делаете некоторую "преждевременную оптимизацию", которые являются, на самом деле, лучшими практиками, потому что выполнение иначе, как известно, полностью неэффективно.
, Например, для добавления к списку нормандца:
- Используя конкатенацию StringBuilder в Java (или C#, и т.д.) вместо Строки + Строка (в цикле);
- Предотвращение циклично выполниться в C как:
for (i = 0; i < strlen(str); i++)(потому что strlen здесь является вызовом функции, обходя строку каждый раз, обратился к каждому циклу); - Это кажется в большинстве реализаций JavaScript, это быстрее, чтобы сделать также
for (i = 0 l = str.length; i < l; i++), и это все еще читаемо, так хорошо.
И так далее. Но такая микрооптимизация никогда не должна происходить за счет удобочитаемости кода.
Оптимизация может произойти на разных уровнях гранулярности от очень высокого уровня до очень низкого уровня:
-
Запускаются с хорошей архитектуры, слабой связи, модульного принципа, и т.д.
-
Выбирают правильные структуры данных и алгоритмы для проблемы.
-
Оптимизируют для памяти, пытаясь приспособить больше кода/данных в кэше. Подсистема памяти в 10 - 100 раз медленнее, чем ЦП, и если Ваши данные разбиты на страницы к диску, это в 1 000 - 10 000 раз медленнее. Быть осторожным относительно потребления памяти, более вероятно, обеспечит главные усиления, чем оптимизация отдельных инструкций.
-
В каждой функции, сделайте соответствующее использование операторов управления потоком. (Переместите неизменные выражения за пределами тела цикла. Поместите наиболее распространенное значение сначала в переключатель/случай, и т.д.)
-
В каждом операторе, используйте самые эффективные выражения, приводящие к корректному результату. (Умножьтесь по сравнению со сдвигом, и т.д.)
Мелочные придирки о том, использовать ли выражение деления или выражение сдвига, не обязательно преждевременная оптимизация. Это только преждевременно, если Вы делаете так без первой оптимизации архитектуры, структур данных, алгоритмов, объема потребляемой памяти и управления потоком.
И конечно, любой оптимизация преждевременна, если Вы не определяете порог производительности цели.
В большинстве случаев, также:
А можно добраться до порога производительности цели путем выполнения высокоуровневой оптимизации, таким образом, не необходимо играть с выражениями.
или
B) Даже после выполнения всей возможной оптимизации, Вы не встретите свой порог производительности цели, и оптимизация низкого уровня не делает достаточно разницы в производительности для выравнивания по ширине потери удобочитаемости.
, По моему опыту, большинство проблем оптимизации может быть решено или в архитектуре/дизайне или в уровне структуры данных/алгоритма. Оптимизация для объема потребляемой памяти часто (хотя не всегда), призвал. Но редко необходимо оптимизировать управление потоком & логика выражения. И в тех случаях, где это на самом деле необходимо, это редко достаточно.
При программировании много параметров жизненно важны. Среди них:
- Удобочитаемость
- Пригодность для обслуживания
- Сложность
- Устойчивость
- Правильность
- Производительность
- Время разработки
Оптимизация (идущий для производительности) часто происходит за счет других параметров и должна быть сбалансирована относительно "потери" в этих областях.
, Когда у Вас есть опция выбора известных алгоритмов, которые работают хорошо, стоимость "оптимизации" заранее часто приемлема.
Я пытаюсь только оптимизировать, когда проблема производительности подтверждена.
Моим определением преждевременной оптимизации является 'усилие, потраченное впустую на код, который, как известно, не является проблемой производительности'. Существует совершенно определенно время и место для оптимизации. Однако прием должен потратить дополнительные расходы только там, где это рассчитывает к производительности приложения и где дополнительная стоимость перевешивает хит производительности.
При записи кода (или запрос DB) я стремлюсь записать 'эффективный' код (т.е. код, который выполняет его намеченную функцию, быстро и полностью с самой простой разумной логикой.) Отмечают, что 'эффективный' код является не обязательно тем же как 'оптимизированным' кодом. Оптимизации часто вводят дополнительную сложность в код, который увеличивает и затраты на разработку и стоимость обслуживания того кода.
Мой совет: Попытайтесь только оплатить стоимость оптимизации, когда можно будет определить количество преимущества.
Точка принципа - то, что, обычно , оптимизация является замысловатой и сложной. И обычно , Вы архитектор/разработчик/программист/специалист по обслуживанию должен очиститься и краткий код для понимания то, что продолжается.
, Если конкретная оптимизация является четкой и краткой, не стесняйтесь экспериментировать с нею (но действительно возвратитесь и проверьте, является ли та оптимизация эффективной). Точка должна держать код в стороне и краткий в течение процесса разработки, пока преимущества производительности не перевешивают вызванные затраты на запись и поддержание оптимизации.
С точки зрения базы данных, для не рассмотрения оптимального дизайна в стадии проектирования безрассудно в лучшем случае Базы данных не осуществляют рефакторинг легко. Как только они плохо разработаны (это - то, что дизайн, который не рассматривает оптимизацию, неважно, как Вы могли бы попытаться скрыться позади ерунды преждевременной оптимизации), почти никогда не в состоянии восстановить с этого becasue, база данных является слишком основной к операции целой системы. Это является намного менее дорогостоящим для разработки правильно рассмотрения оптимального кода для ситуации, которую Вы ожидаете, чем ожидать до существует миллион пользователей, и люди кричат becasue, Вы использовали курсоры всюду по приложению. Другая оптимизация, такая как использование sargeable кода, выбор, что надеется быть самыми лучшими индексами, и т.д. только имейте смысл делать во время проектирования. Существует причина, почему быстрый и грязный назван этим. Поскольку это не может работать хорошо никогда, не используйте быстроту вместо хорошего кода. Также откровенно, когда Вы понимаете настраивание производительности баз данных, можно записать код, который, более вероятно, будет работать хорошо в то же время или меньше, чем это берет для записи кода, который не работает хорошо. Занимание время для изучения, что является хорошим проектированием баз данных выполнения, является ленью разработчика, не лучшей практикой.
То, о чем Вы, кажется, говорите, является оптимизацией как использование основанного на хеше контейнера поиска по сравнению с индексируемым как массив, когда много ключевых поисков будет сделано. Это не преждевременная оптимизация, но что-то, что необходимо решить в стадии проектирования.
вид оптимизации, о которой правило Knuth, минимизирует длину наиболее распространенные пути выполнения кода, оптимизируя код, который выполняется больше всего, например, переписывая в блоке или упрощая код, делая его менее общим. Но выполнение этого имеет быть бесполезное, пока Вы не уверены, каким частям кода нужен этот вид оптимизации, и оптимизация будет (мог?) делают код тяжелее, чтобы понять или поддержать, следовательно "преждевременная оптимизация является корнем всего зла".
Knuth также заявляет, что всегда лучше, вместо оптимизации, изменить алгоритмы Ваше использование программы, подход, который это проявляет к проблеме. Например, тогда как немного тонкой настройки могло бы дать Вам 10%-е увеличение скорости с оптимизацией, изменив существенно путь, Ваши работы программы могли бы сделать его 10x быстрее.
В реакции на большое количество других комментариев отправил по этому вопросу: выбор алгоритма! = оптимизация
Во-первых, получите работу кода. Во-вторых, проверьте, что код корректен. В-третьих, сделайте его быстро.
Любой код изменение , который сделан, прежде чем этап № 3 определенно преждевременен. Я не совсем уверен, как классифицировать проектные решения, сделанные перед тем (как использование подходящих структур данных), но я предпочитаю поворачивать к использованию абстракций, TAHT легко к программе с, а не тем, кто хорошо работает, пока я не на этапе, где я могу начать использовать профилирование и наличие корректного (хотя часто замедляются), ссылочная реализация для сравнения результатов с.
Мой вопрос, если конкретная техника отличается, но не особенно неясна или запутана, который можно действительно считать преждевременной оптимизацией?
Гм... Таким образом, у Вас есть два метода, готовые под рукой, идентичные в стоимости (то же усилие использовать, считайте, измените), и каждый более эффективен. Нет, использование более эффективного, в этом случае, не было бы преждевременно.
Прерывание Вашей записи кода для поиска альтернатив общему программированию создает / библиотечные подпрограммы на всякий случай, что существует более эффективная версия, бродящая вокруг где-нибудь даже при том, что для всего Вы знаете относительную скорость того, что Вы пишете, никогда не будет на самом деле иметь значения... Это преждевременно.
Если Вы не представили, это преждевременно.
По моему скромному мнению, 90% Вашей оптимизации должны произойти в стадии проектирования, на основе воспринятого тока, и что еще более важно, будущие требования. Если необходимо вынуть профилировщика, потому что приложение не масштабируется к необходимой загрузке, Вы оставили его слишком поздно, и IMO потратит впустую много времени и усилия при отказе исправить проблему.
Обычно единственная оптимизация, которая стоит, является теми, которые получают Вас повышение производительности порядка величины с точки зрения скорости или множитель с точки зрения устройства хранения данных или пропускной способности. Эти типы оптимизации обычно касаются выбора алгоритма и стратегии хранения, и являются чрезвычайно трудными инвертировать в существующий код. Они могут пойти настолько же глубоко как влияние на решение о языке, на котором Вы реализуете свою систему.
Так мой совет, оптимизируйте рано, на основе Ваших требований, не Вашего кода, и обратитесь к возможной расширенной жизни своего приложения.
Вот проблема, которую я вижу во всей концепции предотвращения преждевременной оптимизации.
Есть разрыв между высказыванием этого и выполнением этого.
Я много настраивал производительность, сжимая большие факторы из хорошо спроектированного кода, казалось бы, без преждевременной оптимизации. Вот пример.
Почти во всех случаях причиной неоптимальной производительности является то, что я называю скачкообразной общностью , которая заключается в использовании абстрактных многослойных классов и тщательного объектно-ориентированного проектирования , где простые концепции были бы менее элегантными , но полностью достаточными.
И в учебном материале, где преподаются эти абстрактные концепции дизайна, такие как архитектура, управляемая уведомлениями, и скрытие информации, где просто устанавливается логическое значение свойство объекта может иметь неограниченный волновой эффект действий, в чем причина? Эффективность .
Итак, это была преждевременная оптимизация или нет?