Что влияет на скорость кода?

Question

Что влияет на скорость кода?

попробуйте это

import { Storage } from 'aws-amplify'

const getImgUrl = key => {
    return Storage.get(key)
    .then(res => (res))
    .catch(err => console.log(err))
  }

class Image extends Component {
   this.state = {
     imgSrc: null
   }

  componentDidMount(){
      getImgUrl(this.props.img).then(src => {
        this.setState({imgSrc: src});
      });
   }

  render() {

     if(!this.state.imgSrc) {
       return null;
     }

       return <img src={this.state.imgSrc} />;
    }
}

class Images extends Component {
  render() {
    return(
      <div>
        {arrayWithObjects.map(({img}) => (
          <Image img={img} />
        )}
      </div>
    )
  }
}

9

performance profiling

задан Vordreller 6 March 2009 в 20:49

12 ответов

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

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

Некоторые "факторы" скорости кода:

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

4

ответ дан 4 December 2019 в 06:02

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

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

Например: Я просто провел прошлые два дня, ускоряя способ, которым мы повторно вычислили определенное множество значений. Я дергал некоторый материал из цикла и предварительно вычислил его, таким образом, он был только сделан времена M вместо M x N времена и сохранил значение в переменной вместо того, чтобы смотреть он каждый раз от где-то в другом месте, потому что то значение использовалось в Компараторе, таким образом, это назовут много во время фазы Collections.sort. Я получил общее время выполнения приблизительно от 45 секунд до 20 секунд. И затем один из моих коллег, на которых здесь намного дольше указали, что я не должен был повторно вычислять те значения, я мог вытащить их из другого объекта. И внезапно это выполняется за 2 секунды. Теперь, когда оптимизация, я могу верить в.

10

ответ дан 4 December 2019 в 06:02

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

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

4

ответ дан 4 December 2019 в 06:02

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

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

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

3

ответ дан 4 December 2019 в 06:02

Если код имеет "скорость", неправильный способ думать о проблеме, IMO.

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

2

ответ дан 4 December 2019 в 06:02

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

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

В первую очередь, очевидно, Word Size. Машины на 64 бита имеют больший размер слова (да, больше обычно означает лучше здесь) так, чтобы большинство операций могло быть выполнено быстрее, что касается операций двойной точности в качестве примера (где дважды обычно означает 2 * 32 бита). Архитектура на 64 бита также извлекает выгоду из более крупной шины данных, которые обеспечивают более быстрые скорости передачи данных.

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

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

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

Некоторые инструкции имеют зависимости. Если я добавлю к регистрам вместе, то для выполнения фазы добавить инструкции будут нужны значения, прежде чем они будут на самом деле восстановлены из памяти. Путем знания конвейерной структуры компилятор может переупорядочить инструкции по сборке для обеспечения достаточного "расстояния" между загрузками и добавлением так, чтобы ЦП не ожидал.

Другая оптимизация ЦП будет суперскалярной, который использует избыточный ALUs (например) так, чтобы два добавили, что инструкции могут быть выполнены одновременно. Снова, путем знания точно архитектуры можно оптимизировать упорядочивание инструкций воспользоваться преимуществом. Например, если компилятор не обнаруживает зависимостей, существует в коде, он может перестроить загрузки и арифметику так, чтобы арифметика была отложена к более позднему месту, где все данные доступны, и затем выполните 4 операции одновременно.

Это главным образом используется компиляторами все же.

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

// Make an array, in memory this is represented as a 1.000.000 contiguous bytes
byte[][] array1 = new byte[1000, 1000];
byte[][] array2 = new byte[1000, 1000;
// Add the array items

for (int j = 0; j < 1000; i++)
  for (int i = 0; i < 1000; j++)
     array1[i,j] = array1[i,j] + array2[i,j]

Давайте посмотрим то, что происходит здесь.

array1[0,0] принесен для кэширования. Так как кэш работает в блоках, Вы получаете первые 1 000 байтов в кэш, так, чтобы кэш содержал array1[0,0] к array1[0,999].

array2[0,0] принесен для кэширования. Снова блоки так, чтобы у Вас был array2[0,0] к array2[0,999].

На следующем шаге мы получаем доступ array1 [1,0], который не находится в кэше, и ни один не array2[1,0], таким образом, мы приносим им из памяти для кэширования. Теперь, если мы предположим, что у нас есть очень мало размера кэша, то это сделает array2 [0... 999], чтобы быть вынутым из кэша... и так далее. Таким образом, то, когда мы получаем доступ array2 [0,1] к нему, больше не будет в кэше. Кэш не будет полезен для array2 или array1.

Если мы переупорядочиваем доступы памяти:

for (int i = 0; i < 1000; i++)
  for (int j = 0; j < 1000; j++)
     array1[i,j] = array1[i,j] + array2[j,i]

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

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

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

4

ответ дан 4 December 2019 в 06:02

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

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

Таким образом в конце алгоритм.

Дополнительно (только для комментирования различия между скоростью кода и скоростью программы)

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

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

1

ответ дан 4 December 2019 в 06:02

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