ginnie, полностью с Вами согласен. Просто подумал, а вдруг что-то упустил, какую-нибудь интересную мелочь? 

Поигрался с модулем Devel::Size, заодно провел небольшое исследование о памяти, занимаемой различными структурами. Использовал функцию size(), подсчитывающую память, занимаемую самой структурой (в случае нескаляров -- без данных). В модуле есть еще функция total_size() (память для структуры вместе с данными), но она глючит на хэшах. Вот результаты:

undef
12 b

Целые числа
0-4294967296 (2**32) 16 b, далее 20 b

Числа с floating point
20 b

Строки
28 + $n - $n%4 
($n - длина строки)

Массивы
Анонимный массив 
56 + @$aref*4 + $data
(@$aref - число элементов массива, $data - суммарный объем данных, вычисляемый по предыдущим формулам)
Именованный массив
Почему то все сложнее, четкой закономерности я не обнаружил, но приближенно верна формула для анонимного массива
В первом приближении -- данные + 4 байта на каждый элемент

Хеши
Совсем все сложно
(92 + (22+length($key))*$n + 2**(length(sprintf("%b",$n))+2)-32) + $data
Это приближенная формула (в некоторых случаях она не дает точное значение). length($key) - длина ключа хэша (я использовал ключи одинаковой длины, для прикидок можно брать среднюю длину ключа, или максимальную, чтобы с запасом), $n - число элементов хэша (пар ключ-значение), $data - суммарный объем данных (при вычислении нужно помнить, что ключи, как оказалось, если они числа, автоматически превращаются в строки и памяти занимают больше).
В нулевом приближении -- данные + 32 байта на каждый элемент.

Пример того, что хэшами нужно пользоваться с осторожностью
Стандартная задача: организовать быстрый доступ к элементам массива (не по номеру, а по значению). Используют преобразование массива в хэш.
Массив из миллиона целых чисел [1..1000000] занимает в памяти очень умеренные по нынешним временам 20 М.
Хэш {map {$_=>""} 1..1000000}, полученный из этого массива, занимает 410 М. Уже опасно даже по нынешним временам. Использование в качестве значений хэша undef вместо пустой строки "" помогает, но не спасает (экономит лишь 16 М; основное место, 320 М, в этом хэше занимают не данные, а сама структура).

_____________________________
PS Все эти формулы я толком не тестировал, может, они и неправильные. Очевидно, будет зависимость от архитектуры машины и, возможно, от версии Perl (у меня - linux x32, perl 5.8.8)
_____________________________
PPS Что-то я туплю. Как проще вычислить для числа ближайшую к нему (снизу) степень двойки? (вместо того, что у меня  2**(length(sprintf("%b",$n))) )

Это сообщение отредактировал(а) amg - 10.7.2008, 08:28

Если делать по стандарту, то 

Но не думаю, что будет сильный выигрыш во времени  Даже может наоборот.

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

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

Может, специалист имел в виду, что переменная может занять все свободную память, и ее (память) не нужно для этого отводить?

Хм.. думаю будет по сабжу. Давно интересовал такой вопрос.

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

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

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

При этом еще переменныя $+ заполняется тем же самым.

Во многих случаях хеши можно заменить массивами. Можно даже "изобразить" доступ по ключу для удобства:



хотя, зачастую вместо констант используется такая конструкция:


http://www.perl.com/doc/manual/html/pod/pe...stant_Functions

в http://www.perl.com/doc/manual/html/lib/constant.html пишут, что:

In the current implementation, scalar constants are actually inlinable subroutines. As of version 5.004 of Perl, the appropriate scalar constant is inserted directly in place of some subroutine calls, thereby saving the overhead of a subroutine call. See Constant Functions for details about how and when this happens. 

Интересно, как сейчас с этим обстоят дела. Если константа это функция, это ведь оверхед получается неслабый...

попробовал 


У меня массив из 1000 элементов занимал 24 килобайта, а хеш - 52 килобайта. Т.е. хеш в 2 раза дороже. 
Если использовать массив с константами в качестве "индексов" то к массиву плюс 20 * 1000 = 20 килобайт займут константы. 
Итого размер массива + константы примерно будет равен хешу, что сведет преимущества к нулю.

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

Это сообщение отредактировал(а) Ramirez - 19.8.2008, 18:09

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



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