Antoshka

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

Antoshka
Ты хоть читаешь, то что пишут? Если у тебя x64, то всё будет ОК.

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


дальше у тебя много слов опять не по теме, комментировать не буду. Повторю исходный вопрос - он был не в том, почему приложение не может воспользоваться более чем N гигабайтами оперативы, он был в том, почему .net не использует виртуальную память. Разницу способен понять? И ответ на этот вопрос лежит не в статьях про Win32, а в описании CLR и сборщика мусора и особенностях их работы. Иди читай, потом расскажешь.

Antoshka
Запусти, и увидишь, что далее двух шагов она не пройдёт, если, конечно процесс не x64 (в этом случае она будет продолжать работать до исчерпания ОЗУ и файла подкачки). Но, опять же, топикстартер не упомянул версию своей операционной системы.
ололо, а у меня даже один шаг ниасилила, к чему бы это? винда 2008 x32, 2гб оперативы.

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

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

МСУ, тебя-то драли, дерут и драть будут, до сих пор иногда ржу над твоими перлами. Надолго разбанили-то?

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

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

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

серверные курсоры обладают феноменально низкой производительностью, кроме того, не имеют должной поддержки со стороны ado.net. Наверное, ты все-таки хотел воспользоваться пейджингом?