Является ли преждевременная оптимизация корнем всего зла?

Сегодня мой коллега совершил класс под названием ThreadLocalFormat , который в основном перемещал экземпляры классов Java Format в поток локальный, поскольку они не являются потокобезопасными и «относительно дорогими» для создания. Я написал быстрый тест и подсчитал, что могу создать 200 000 экземпляров в секунду, спросил его, создает ли он столько, на что он ответил «нигде рядом с этим». Он отличный программист, и все в команде высококвалифицированы, поэтому у нас нет проблем с пониманием полученного кода, но это был явно пример оптимизации, где нет реальной потребности. Он поддержал код по моей просьбе. Как вы думаете? Это случай «преждевременной оптимизации» и насколько это плохо?

183 голоса | спросил 2 revs, 2 users 67%
Craig Day
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

17 ответов


285

Важно иметь в виду полную цитату:

  

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

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

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

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
93

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

Каковы хорошие ранние оптимизации в порядке важности:

  • Архитектурные оптимизации (структура приложения, его компонентность и многоуровневость)
  • Оптимизация потока данных (внутри и снаружи приложения)

Некоторые средние оптимизации цикла разработки:

  • Структуры данных, при необходимости внедряют новые структуры данных, которые имеют более высокую производительность или меньшие накладные расходы
  • Алгоритмы (теперь самое подходящее время для принятия решения между quicksort3 и heapsort ;-))

Оптимизация цикла конечного цикла разработки

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

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

Если производительность вызывает озабоченность (и всегда должна быть), всегда думайте большой . Производительность - это большая картина, а не такие вещи, как: следует ли использовать int или long ?. Перейдите в Верх вниз при работе с производительностью вместо Bottom Up .

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
46

Оптимизация без предварительного измерения почти всегда преждевременна.

Я считаю, что это правда в этом случае, и верно и в общем случае.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
39

Оптимизация «зла», если она вызывает:

  • менее четкий код
  • значительно больше кода
  • менее безопасный код
  • потраченное время программиста

В вашем случае кажется, что немного времени программиста уже было потрачено, код был не слишком сложным (угадайте из своего комментария, что все в команде могли бы понять), а код - немного больше будущего доказательство (теперь потокобезопасность, если я понял ваше описание). Похоже, только немного зла. :)

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
29

Я удивлен, что этот вопрос составляет 5 лет, и все же никто не опубликовал больше того, что должен был сказать Кнут, чем несколько предложений. Пара абзацев, окружающих знаменитую цитату, объясняет это довольно хорошо. Бумага, которая цитируется, называется « Структурированное программирование с переходом к заявлениям », и хотя это почти 40 лет, представляет собой спор и движение программного обеспечения, которое уже не существует, и имеет примеры в языках программирования, о которых многие люди никогда не слышали, удивительно большое количество того, что он сказал, все еще применяется.

Вот большая цитата (со страницы 8 из pdf, стр. 268 в оригинале):

  

Улучшение скорости от примера 2 до примера 2а составляет лишь около 12%, и многие люди произносят это незначительное. Традиционная мудрость, которую разделяют многие современные программисты, требует игнорирования эффективности в малом; но я считаю, что это просто чрезмерная реакция на злоупотребления, которые, как они видят, практикуются программистами, которые не могут отлаживать или поддерживать свои «оптимизированные» программы. В установленных инженерных дисциплинах улучшение на 12%, легко получаемое, никогда не считается маргинальным; и я считаю, что одна и та же точка зрения должна преобладать в разработке программного обеспечения. Конечно, я бы не стал заниматься такой оптимизацией на одноразовой работе, но когда речь идет о подготовке качественных программ, я не хочу ограничивать себя инструментами, которые лишают меня такой эффективности.

     

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

     

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

Еще один хороший бит с предыдущей страницы:

  

Мой собственный стиль программирования, конечно, изменился в течение последнего десятилетия, в соответствии с тенденциями времени (например, я не так уж сложен, и я использую меньшее количество ходов), но основные изменения в моем стиле вызвано этим явлением внутренней петли. Теперь я смотрю с чрезвычайно раздражительным взглядом на каждую операцию в критическом внутреннем цикле, стремясь изменить мою программу и структуру данных (как при изменении от примера 1 к примеру 2), так что некоторые операции можно устранить. Причины такого подхода заключаются в следующем: а) это не займет много времени, поскольку внутренний цикл короток; б) выигрыш реален; и c) я могу позволить себе быть менее эффективным в других частях моих программ, которые поэтому более читабельны и более легко записываются и отлаживаются.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
15

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

В целом, я думаю, что ранняя микро-оптимизация может быть плохой идеей. Тем не менее, макрооптимизация (например, выбор алгоритма O (log N) вместо O (N ^ 2)) часто стоит и нужно делать раньше, так как может быть расточительно писать алгоритм O (N ^ 2) и затем полностью отбросьте его в пользу подхода O (log N).

Обратите внимание, что слова могут быть : если алгоритм O (N ^ 2) прост и прост в написании, вы можете выбросить его позже без большой вины, если он окажется слишком медленным. Но если оба алгоритма одинаково сложны или ожидаемая рабочая нагрузка настолько велика, что вы уже знаете, что вам понадобится более быстрый, то оптимизация на раннем этапе - это решение для инженерной инженерии, которое сократит вашу общую нагрузку в конечном итоге.

Таким образом, в целом, я думаю, что правильный подход заключается в том, чтобы выяснить, каковы ваши варианты, прежде чем начинать писать код, и сознательно выбирать лучший алгоритм для вашей ситуации. Самое главное, что фраза «преждевременная оптимизация - корень всего зла» не является оправданием невежества. Разработчики карьеры должны иметь общее представление о том, сколько общих операций стоит; они должны знать, например,

  • , что строки стоят больше, чем числа
  • , что динамические языки намного медленнее, чем статически типизированные языки
  • преимущества списков массива /вектора по связанным спискам и наоборот
  • , когда использовать хэш-таблицу, когда использовать отсортированную карту и когда использовать кучу
  • что (если они работают с мобильными устройствами) «double» и «int» имеют сходную производительность на рабочих столах (FP может даже быть быстрее), но «double» может быть в сто раз медленнее на мобильных устройствах младшего класса без FPU;
  • , что передача данных через Интернет происходит медленнее, чем доступ к жесткому диску, жесткие диски значительно медленнее, чем оперативная память, оперативная память намного медленнее, чем кеш-память L1 и регистры, а интернет-операции могут блокироваться бесконечно (и сбой в любое время).

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

Наличие большого количества знаний и личного инструментария позволяет оптимизировать практически без усилий. Приложив много усилий к оптимизации, которая может оказаться ненужной, - это зло (и я допускаю, что попадаю в эту ловушку не один раз). Но когда оптимизация так же просто, как выбор набора /хэш-таблицы вместо массива или сохранение списка чисел в double [] вместо строки [], то почему бы и нет? Возможно, я не согласен с Кнутом, я не уверен, но я думаю, что он говорил о оптимизации на низком уровне, тогда как я говорю о оптимизации на высоком уровне.

Помните, что цитата изначально была с 1974 года. В 1974 году компьютеры были медленными, а вычислительная мощность была дорогостоящей, что дало некоторым разработчикам склонность к переопределению, по очереди. Я думаю, это то, к чему настаивал Кнут. Он не говорил «не волнуйтесь о производительности вообще», потому что в 1974 году это было бы просто сумасшедшим разговором. Кнут объяснял , как оптимизировать; Короче говоря, следует сосредоточиться только на узких местах, и прежде чем вы это сделаете, вы должны выполнить измерения, чтобы найти узкие места.

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

Как рано оптимизировать и насколько беспокоиться о производительности зависит от работы. При написании сценариев, которые вы будете запускать только несколько раз, беспокоиться о производительности вообще - это, как правило, полная трата времени. Но если вы работаете в Microsoft или Oracle, и вы работаете над библиотекой, в которой тысячи других разработчиков будут использоваться тысячами разных способов, она может заплатить за то, чтобы оптимизировать ее, поэтому что вы можете эффективно использовать все разнообразные варианты использования. Тем не менее, потребность в производительности всегда должна быть сбалансирована с потребностью в удобочитаемости, ремонтопригодности, элегантности, расширяемости и т. Д.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
12

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

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

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

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
8

На самом деле я узнал, что преждевременная не-оптимизация чаще всего является корнем всего зла.

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

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

Посмотрите на Боча. Это медленно, черт возьми. Станет ли он быстрее? Может быть, но только в диапазоне нескольких процентов. Он никогда не получит производительности, сравнимой с программным обеспечением для виртуализации, таким как VMWare или VBox или даже QEMU. Потому что это медленно по дизайну!

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

Поэтому, если производительность для вашего программного обеспечения является ВАШИМ важным, вы должны учитывать это с самого начала при разработке, вместо того, чтобы думать «о, да, это медленно, но мы можем улучшить это позже». Потому что вы не можете!

Я знаю, что это действительно не подходит для вашего конкретного случая, но отвечает на общий вопрос: «Преждевременная оптимизация действительно является корнем всего зла?» - с четким NO.

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

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

Глубокая оптимизация более зла, чем «преждевременная» оптимизация, но оба они все же лучше, чем преждевременная не оптимизация.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
6

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

В принципе, да, это звучит как преждевременная оптимизация, но я бы не стал отказываться от нее, если она не вводит ошибки - в конце концов, теперь она оптимизирована (!)

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
3

Я считаю, что Майк Кон называет «золотом» код, т. е. тратит время на то, что может быть приятным, но не необходимым.

Он посоветовал против этого.

P.S. «Покрытие золотом» может быть колоколами и свистками. Когда вы смотрите на код, он принимает форму ненужной оптимизации, «будущие» классы и т. Д.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
3

Так как нет проблем с пониманием кода, тогда этот случай можно рассматривать как исключение.

Но в целом оптимизация приводит к менее читабельному и менее понятному коду и должна применяться только при необходимости. Простой пример - если вы знаете, что вам нужно сортировать только пару элементов, то используйте BubbleSort. Но если вы подозреваете, что элементы могут увеличиться, и вы не знаете, сколько, то оптимизация с помощью QuickSort (например) не является злом, а обязательным. И это следует учитывать при разработке программы.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
3

Я обнаружил, что проблема с преждевременной оптимизацией в основном происходит, когда переписывание существующего кода происходит быстрее. Я вижу, как это может быть проблемой для написания некоторой свернутой оптимизации в первую очередь, но в основном я вижу преждевременную оптимизацию, воспитывая свою уродливую голову в исправлении того, что не было (как известно, было) сломалось.

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

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

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
3

С другой стороны, мой опыт показывает, что большинство программистов /разработчиков не планируют успех, а «прототип» почти всегда становится версией 1.0. У меня есть опыт работы с 4 отдельными оригинальными продуктами, в которых стильный, сексуальный и высокофункциональный интерфейс (в основном, пользовательский интерфейс) привел к широкому распространению и энтузиазму пользователей. В каждом из этих продуктов проблемы с производительностью начали закрадываться в течение относительно коротких времен (от 1 до 2 лет), особенно в качестве более крупных, более требовательных клиентов, начали принимать продукт. Очень скоро производительность доминировала над списком проблем, хотя в списке приоритетов управления доминировала новая функция. Клиенты стали все более разочаровываться, так как каждый релиз добавил новые функции, которые звучали великолепно, но были почти недоступны из-за проблем с производительностью.

Таким образом, очень фундаментальные недостатки проектирования и реализации, которые мало или вообще не касались «прото-типа», стали основными препятствиями для долгосрочного успеха продуктов (и компаний).

Ваша клиентская демонстрация может выглядеть и отлично работать на вашем ноутбуке с XML DOM, SQL Express и множеством клиентских кешированных данных. Система производства, вероятно, сработает, если вы добьетесь успеха.

В 1976 году мы все еще обсуждали оптимальные способы расчета квадратного корня или сортировки большого массива, и пословица Дона Кнута была направлена ​​на ошибку, фокусируясь на оптимизации такого рода низкоуровневой процедуры на ранней стадии процесса проектирования, а не на решая проблему, а затем оптимизируя локализованные области кода.

Когда один повторяет пословицу в качестве предлога для того, чтобы не писать эффективный код (C ++, VB, T-SQL или иначе) или для неправильной разработки хранилища данных или для не рассматривания архитектуры сетевой работы, тогда IMO они просто демонстрируя очень мелкое понимание реальной природы нашей работы. Ray

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
1

Я полагаю, это зависит от того, как вы определяете «преждевременное». Быстрое выполнение низкоуровневой функциональности, когда вы пишете, по своей сути не является злом. Я думаю, что это недоразумение в цитате. Иногда я думаю, что цитата могла бы сделать с некоторой дополнительной квалификацией. Тем не менее, я бы ответил на комментарии m_pGladiator о читаемости.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
1

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

В некоторых случаях вы можете проектировать для эффективности или производительности (воспринимаемых или реальных) - выбор подходящего алгоритма или проектирование пользовательского интерфейса, поэтому некоторые неопытные операции происходят, например, в фоновом режиме. Во многих случаях профилирование или другие операции для определения горячих точек получат вам преимущество 10/90.

Одним из примеров этого я могу описать модель данных, которые я однажды сделал для системы управления судебными делами, в которой было около 560 таблиц. Он начался с нормализации («красиво нормализованный», как выразился консультант от какой-то крупной фирмы-5), и нам нужно было вставить в него четыре элемента денормализованных данных:

  • Один материализованный вид для поддержки экрана поиска

  • Одна таблица, поддерживающая триггер, для поддержки другого экрана поиска, который не может быть выполнен с материализованным представлением.

  • Одна денормализованная отчетная таблица (это было только потому, что нам приходилось принимать некоторые отчеты о пропускной способности, когда проект хранилища данных был закончен)

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

Это был (в то время) самый крупный проект J2EE в Австралии - более 100 лет времени разработчика - и в схеме базы данных было 4 отрицательно обработанных элемента, один из которых на самом деле не принадлежал вообще.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
1

Преждевременная оптимизация не является корнем ВСЕГО Зла, это точно. Есть и недостатки:

  • вы инвестируете больше времени на разработку
  • вы вкладываете больше времени на тестирование.
  • вы вкладываете больше времени на исправление ошибок, которые иначе не были бы там

Вместо преждевременной оптимизации можно было провести ранние тесты на видимость, чтобы увидеть, есть ли настоящая потребность в лучшей оптимизации.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49
1

Большинство тех, кто придерживается «PMO» (частичная цитата, то есть), говорят, что оптимизация должна основываться на измерениях, и измерения не могут выполняться до самого конца.

Это также мой опыт разработки больших систем, что тестирование производительности выполняется в самом конце, так как разработка приближается к завершению.

Если бы мы следовали «советам» этих людей, все системы были бы мучительно медленными. Они также будут дорогими, потому что их потребности в оборудовании намного больше, чем первоначально предполагалось.

Я долго выступал за выполнение тестов производительности через регулярные промежутки времени в процессе разработки: он будет указывать на наличие нового кода (где ранее его не было) и состояние существующего кода.

  • Выполнение недавно реализованного кода можно сравнить с тем, что существующего, аналогичного кода. «Чувство» для производительности нового кода будут установлены с течением времени.
  • Если существующий код внезапно уходит, вы понимаете, что что-то случилось с ним, и вы можете немедленно его расследовать, а не (много) позже, когда он влияет на всю систему.

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

Отметьте этот отличный пример того, что PMO может или не имеет значения.

ответил daemondave 25 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 25 Sep 2015 23:54:49 +0300 2015, 23:54:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132