Я должен всегда думать о производительности?

Вот мой трюк:

public class Main {

    public static void main(String[] args) throws Exception {

        System.out.println(Main.<String> getClazz());

    }

    static <T> Class getClazz(T... param) {

        return param.getClass().getComponentType();
    }

}
18
задан FerranB 20 April 2009 в 11:10
поделиться

21 ответ

Вообще говоря, быть завладением о производительности или оптимизации является маршрутом к большому количеству зла в разработке программного обеспечения. Обычно, только приблизительно 5% (или меньше!) Вашего кода оказывает любое влияние на производительность полной системы. Ваши основные цели, во-первых, поскольку разработчик программного обеспечения на большинстве проектов добирается для исправления и надежная функциональность и также конечно, пригодность для обслуживания системы. Затем когда-то реализованный и работающий правильно, Вы оцениваете производительность, узнаете, где узкие места и оптимизируют их соответственно для удовлетворения полным целям.

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

17
ответ дан 30 November 2019 в 06:12
поделиться

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

Тем не менее производительность важна, но она может вести для разрушения.

Рассвет войны 2 был выпущен в феврале с игровой ошибкой повреждения, которая уничтожает многопользовательский. Проблема? Ограничение населения. Когда команда укреплена, последняя единица поднимает дважды ограничение из-за ошибки кодирования. Это означает, что можно быть в ситуации, где у Вас есть очень малочисленная армия и когда Вы пытаетесь создать новую единицу, игра говорит Вам, что у Вас есть слишком много единиц на поле. Самый печальный.

, Почему это должно быть проблемой? Как это может быть проблемой, которая только происходит с укреплением? Если бы это была проблема только с покупкой единицы тогда, конечно, это было бы обнаружено в тестировании!

Хорошо мое предположение - то, что это происходит из-за преждевременной оптимизации. Разработчик не хотел к foreach всех единиц, когда Вы нажимаете кнопку "buy unit" и вместо этого сделанный поп-ограничением как банк поэтому, когда единица создается, это вынимает ограничение из банка и когда это умирает, поп-ограничение отложено в банк. Уверенный это более производительно, но одна небольшая ошибка бросает целый банк не в ногу.

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

В большом количестве случаев его более обеспеченная маркировка

// todo: performance could be better
// try doing xyz if we need to improve it

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

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

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

0
ответ дан 30 November 2019 в 06:12
поделиться

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

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

0
ответ дан 30 November 2019 в 06:12
поделиться

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

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

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

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

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

Мы не можем предсказать каждую проблему. Я пытаюсь сделать хороший дизайн и позволить проблемной борьбе за мое внимание.

Hope что-то было полезно.

0
ответ дан 30 November 2019 в 06:12
поделиться

Ответ 1:

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

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

Ответ 2:

Иногда простое рабочее решение Вы сначала придумываете выполнения в O(n^n) время. Если Вы будете знать , то Вы будете иметь большие наборы данных, то идти вперед и оптимизировать его теперь.

Ответ 3:

Некоторое время назад, я устал от пятен в PHP и попытался зафиксировать некоторых из них. Я записал платформу, которая включила базовый класс, которому все должно было наследоваться. Это использовало метод и перегрузку свойства, отражение и примерно любую расширенную функцию, чтобы заставить его работать. Затем я шел вперед и использовал его в крупном проекте, используя мои собственные функции платформы вместо основные возможностей языка как isset() и static. Код проекта был немного более опрятным, но волшебство замедлило каждый вызов метода и доступ свойства приблизительно 50x.

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

0
ответ дан 30 November 2019 в 06:12
поделиться

Это обычно сводится к требованиям. В некоторых случаях у Вас есть очень строгие нефункциональные требования в течение времени отклика, и т.д. В тех случаях, необходимо быть дополнительным усилием настроить код, процедуры, и т.д.

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

0
ответ дан 30 November 2019 в 06:12
поделиться

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

Другой пример... в моем предыдущем задании я работал в Обработке данных, пишущий сценарии вокруг исполняемых программ. Если я запустил программу в 17:00 ночью, и она закончилась к 8:00 следующим утром, это было достаточно быстро. Конечно, в случае чрезвычайной ситуации для него было намного лучше занять один час вместо десять, и более быстрый код сделал мое задание легче, но , пока это работало правильно , 30 минут были эквивалентны 16 часам.

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

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

0
ответ дан 30 November 2019 в 06:12
поделиться

Я нахожу, что мой типичный шаблон для работы через единицу разработки:

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

  2. Шаг 2 должен осуществить рефакторинг шаг 1 главным образом глазом к упрощению. Так как я делал ООП, одна вещь, на которую я, кажется, могу рассчитывать, состоит в том, что этот шаг всегда представляет много очевидных упрощений и фактического сокращения кода. Это также - точка, где очевидные абстракции выпадают (который является другим упрощением.) ВАЖНОЕ ПРИМЕЧАНИЕ: Это имеет сильный побочный эффект обращения к производительности, особенно когда Вы сделали это несколько раз, и Вы знаете, где производительные антишаблоны.

  3. Часто, когда № 2 сделан, вещи удовлетворительно производительны, но тесты подтвердят это или нет; и также укажите (обычно очень немногие) местоположения, где оптимизация должна быть обращена.

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

0
ответ дан 30 November 2019 в 06:12
поделиться

Я работаю над созданием поисковой системы. Оптимизация - то, что имеет значение между пользователем, продолжающим искать или оставляющий веб-сайт. Я думаю, что Это верно для многих приложений, и к сожалению многие из них не заботятся достаточно об этом. Иногда это намного более дешево что, бросая больше аппаратных средств в проблему. К сожалению, последний легче. Подводя итоги, я сказал бы, что необходимо оптимизировать каждый раз, когда Вы любой должен обработать МНОГО данных и/или обработать его очень быстро.

0
ответ дан 30 November 2019 в 06:12
поделиться

, Когда я должен думать о производительности и если не?

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

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

0
ответ дан 30 November 2019 в 06:12
поделиться

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

1
ответ дан 30 November 2019 в 06:12
поделиться

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

3
ответ дан 30 November 2019 в 06:12
поделиться

Не думайте о производительности, пока у Вас не будет ее работающий правильно. Если это работает правильно, и это не имеет никакого пользователя noticable проблемами производительности, не оптимизировать.

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

  1. оптимизация Архитектуры. Является полная структура приложения источником inneficiency?

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

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

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

2
ответ дан 30 November 2019 в 06:12
поделиться

У меня была фаза, где я был absolutly параноиком о производительности. Я провел так много времени, пытаясь улучшить производительность, что мой код никогда на самом деле прогрессировал. Не входите в ту привычку :-)

Код, ЗАТЕМ оптимизируйте, не оба одновременно.

4
ответ дан 30 November 2019 в 06:12
поделиться

Цитирование 'преждевременной оптимизации Knuth.. зло' является плохим аргументом в пользу написания неаккуратного и медленного кода (корректный или иначе).

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

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

, Если Вы пишете замену поисковой системы Google, и Вы ожидаете иметь большой трафик, затем Вы выясняете способ сделать тот поиск максимально быстро.

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

<час>

, Учитывая, что мы удовлетворяем 1, 2 и 3 выше:

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

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

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

Мои 2 шиллинга, по крайней мере.

5
ответ дан 30 November 2019 в 06:12
поделиться

Я думаю, что существует две противоречащих пословицы, которые релевантны здесь.

1: Преждевременная оптимизация является корнем всего зла.

2: Посмотрите перед прыганием.

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

Это - то, где пословица 2 кажется релевантной. Не полагайтесь на первую пословицу, чтобы не сделать любое планирование производительности, иметь полный план, даже если это развивающееся. Попытка разрабатывает некоторые приемлемые метрики производительности и время Вашу программу. Рассмотрите более поздние последствия производительности проектных решений. Как пример, можно было бы запланировать использовать хранилище кортежа, а не базу данных заранее, если все, что необходимо, является хранилищем кортежа. Запуск с базы данных SQL и затем изменение на кортеж хранят, позже является довольно трудным.

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

5
ответ дан 30 November 2019 в 06:12
поделиться

Когда это делает?

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

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

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

5
ответ дан 30 November 2019 в 06:12
поделиться

кавычка Knuth ("Мы должны забыть о маленькой эффективности, сказать приблизительно 97% времени: преждевременная оптимизация является корнем всего зла"), вероятно, применяется.

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

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

13
ответ дан 30 November 2019 в 06:12
поделиться

Для меня, когда я работаю с обработкой изображения, несколькими большими запросами SQL или циклами, которые передают метку 100k, я думаю об оптимизации. Иначе я не делаю, если я не вижу ее медленное когда его работа.

0
ответ дан 30 November 2019 в 06:12
поделиться

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

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

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

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

Работа над производительностью - это вопрос достижения оптимума, будь то a priori или posteriori .Какая-то работа с производительностью уместна только апостериори , и это то, что следует считать оптимизацией, и преждевременно делать априори . Какая-то исполнительская работа подобна или более уместна априори .

Главное, что нужно попытаться понять априори , - это разумность вашего основного подхода. Здесь часто приводится пример временной сложности алгоритмов, но я не согласен. Не всегда лучше делать что-то за O (1) или O (n log n), чем за O (n). Время O (n) совпадает с временем O (1), когда n равно 1, и быстрее, когда n равно 0, и наборы данных с 0 или 1 элементом могут быть обычными во многих случаях. Более того, обозначение временной сложности намеренно игнорирует члены и константы более низкого порядка. На самом деле время O (n) означает kn + c (и, возможно, другие члены более низкого порядка), в то время как время O (1) означает k + c, , но для разных значений k и c . Если этот алгоритм сам находится внутри цикла, может случиться так, что O (n) значительно превзойдет O (1).

Таким образом, временная сложность - это не то, что нужно здесь учитывать. Здесь необходимо учитывать , следует ли учитывать временную сложность. Если это так, то пора посмотреть, применим ли случай, когда O (n) превосходит O (1) из-за отсутствия накладных расходов, или следует использовать более распространенный случай, когда O (n) превосходит O (1). , или следует ли здесь игнорировать временную сложность и просто делать то, что читается более естественно . Например.Типичный случай конкуренции по временной сложности - использовать ли список и выполнять поиск в нем или набор на основе хеширования и запрашивать его на основе хеша. Однако с большинством библиотек код для каждой будет выглядеть по-разному, поэтому будет тот, который лучше описывает намерение, и тот, который следует использовать, когда он не критичен с точки зрения производительности.

Важным априори здесь было то, стоит ли думать о производительности на данном этапе.

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

Итак, нам нужно подумать с самого начала, хотя нам не нужно решать все на данном этапе.

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

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

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

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

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

Другой важный случай - это когда вы не сможете легко получить информацию о том, как используется код. Если вы пишете приложение, которое используется на одном сайте, вы сможете очень хорошо это измерить. Если вы пишете приложение, которое будет распространяться, это станет труднее. Если вы пишете библиотеку, которая будет использоваться в нескольких разных приложениях, это еще сложнее. В последнем случае аргумент, что ЯГНИ, становится намного слабее; может быть, кому-то действительно нужен этот медленный метод, который нужно значительно улучшить, а вы об этом не знаете. Опять же, подход, который вам нужно использовать, не всегда один и тот же; в то время как один из подходов состоит в том, чтобы заранее поработать, чтобы сделать ее более производительной в этом случае (не совсем априори , поскольку это апостериори , когда ваша библиотека пишется, но априори) к его использованию) другой подход состоит в том, чтобы просто задокументировать, что конкретный метод по необходимости является дорогостоящим и что вызывающий код должен запоминать или иным образом оптимизировать способ его использования в собственном коде , если это приемлемо .

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

0
ответ дан 30 November 2019 в 06:12
поделиться

Я собираюсь в некоторой степени не согласиться с этой стаей.

Вы всегда учитываете производительность, но обычно вы ее игнорируете. Посмотрите, как часто будет запускаться код. Если ответ - «один раз» или «редко», производительность в основном не проблема.

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

Единственный раз, когда я буду рассматривать что-то вроде детальной оптимизации, когда я изначально пишу, это код внутри O (пугающей) подпрограммы. (Пример: тест, чтобы убедиться, что набор данных не содержит тупиков. O (n ^ 8), хотя и с существенным сокращением. Я был осторожен с производительностью с первой строки.)

0
ответ дан 30 November 2019 в 06:12
поделиться
Другие вопросы по тегам:

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