Собственно, насколько они эффективны в плане скорости скорости, размерам занимаемой памяти под служебные нужды и доступе к элементам? Чем массивы типа:


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

Может у вас есть сведения по этой теме?

А ты посмотри какова разница в представлении на asm и по разнице
кол-ва строчек сможешь предположить разницу в скорости.

ё маё...

Добавлено через 1 минуту и 34 секунды
а "внутри " SetLength еще больше ASM инструкций....

Присоединённый файл ( Кол-во скачиваний: 25 )
 untitled.GIF 88,76 Kb

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

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

Провел эксперимент на таком коде 


Проверка показала, что для стекового массива 100млн присваиваний произошли за 328мс, а для массива в куче за 406 мс, т.е. на целых 23% дольше!

Похоже правду говорят про то что стек кешируеться лучше.

Иногда большое кол-во машинный инструкций приводит к более эффективному коду в плане скорости выполнения! Отсюда вывод, надо смотреть не на кол-во инструкций, а на кол-во конструкций c условным переходом, куда я отношу такие как jnX, jX. Этому есть разумный довод, процессор работает так:
1. Выборка новой команды
2. Декодирование команды выбранной в прошлом такте
3. Выполнение инструкции выполненной 2 мя тактами раньше.

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

и так, если есть код:



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

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

Еще раз замечу, современные процессоры, по другим механизмам работают, но классику не стоит забывать, она позволяет оценить код на глаз! ;)

Добавлено через 5 минут и 43 секунды
Вот еще выдержка из unit DCPsha512, компонента DCPcrypt v2.0 written by David Barton:

Есть код:


и есть:


Как вы думаете, почему автор отказался от цикла? и всатвил все напрямую ?

ммм... а ты усреднял результаты? у меня они все время разные - то одно быстрее, то другое. Иногда в два раза. Это если с отключенной оптимизацией. Если с включенной, порядок наблюдается, но в среднем разница все же не 23%, а ~100%...

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

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

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

 Ну да! Память памяти рознь. Одно дело память процессора, а другое системная память. Работают они с разной скоростью. А вот что окажется в этом кэше и когда, вот что интересно. Не зря же разница в 23%.

Добавлено через 2 минуты и 26 секунд
Упс. неправильно понял ответ. Ну да конечно между GetMem и SetLength разницы нет, память будет выделена в любом случае в куче.

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