Доброе время суток, уважаемые форумчане.

Есть задача, в которой необходимо заюзать неопределённое количество памяти с минимальной время-потерей.

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

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

Что значит отхватить?

> Где граница (размер в байтах), превышая которую лучше (быстрее,
>  безопаснее, ...) отхватить кусок из кучи ?

stacksize?

> Zeqfreed ©   (09.08.08 12:33) [2]

что есть "stacksize" ?

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

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

> В общем, нужен человек, который про стек знает многое...


А Рихтер не подходит?
:)

рихтер - это долго.

>рихтер - это долго.
Зато навсегда.

>DevilDevil ©   (09.08.08 12:33) [3]
Ну так-то быстрее. Естественно двинуть указатель и все. Но кто мешает взять в куче сразу большую область и точно также двигать по ней указатели?

> Sergey Masloff   (09.08.08 14:02) [7]
> Зато навсегда.

Если не заблуждаюсь, тема не о пользе прочтения рихтера.

> Но кто мешает взять в куче сразу большую область и точно также
> двигать по ней указатели?

Ну так-то проще - отписать ересь какую-нибудь вместо ответа на чётко сформулированный вопрос.

DevilDevil ©   (09.08.08 14:21) [8]
Терминология на вашей совести.
Никакой четкости в вопросе нет.
Я описал вариант работы с кучей который не будет отличаться от работы со стеком. То есть никакой границы нет. Как в стеке никто (почти) не будет следить за безопасностью так и в куче. Скорость доступа к стеку и к куче может быть практически одинаковой.

вопрос открыт

для резервации больших объемов памяти - куча, для малых - стек
вопрос закрыт

Есть вариант, что оптимизировать надо в другом месте.

> для резервации больших объемов памяти - куча, для малых
> - стеквопрос закрыт

золотые слова!!!
в том то и вопрос: "большой объём" - это сколько байт ?

> DevilDevil ©   (09.08.08 15:06) [10]
> вопрос открыт


Если ты можешь гарантировать что страницы стека будут гарантировано подгружены заранее,т.е. организовать unpageable pool, то стек естественно более предпочтительней поскольку вся операция Alloc это
sub esp, Size.
Однако в противном случае при работе со стеком тебе придется выделять постранично генерируя исключение процессора для выделения физической страницы. Что естественно очень накладно. Тогда предпочтение естественно куча.

НО!!! Я бы выбрал другой вариант

Никто не мешает организовать тебе свой менеджер памяти.  VirtualAlloc тебе в помощь.

> oxffff ©   (09.08.08 15:22) [14]

для объёмов в 4, 10 или 100 байт свой или Delphi-йский менеджер памяти - дело относительно накладное. А вот пару мегабайт уже надо бы в куче делать. Вот и вопрос: где же эта граница ?

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

> дело относительно накладное.


Относительно чего?


> где же эта граница ?


Граница у автора.

>  [15] DevilDevil ©   (09.08.08 15:34)
> Вот и вопрос: где же эта граница
> ?

так проверь свободную физическую память и выбирай

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

вопрос: чему равна
?

> VirEx ©   (09.08.08 15:38) [17]
> так проверь свободную физическую память и выбирай


уточни, пожалуйста.