Чисто теоретический вопрос на запись в файл в начало со сдвигом

← →
NoUser © (2013-05-08 01:44) [40]

> DVM © (07.05.13 22:49) [36]
> ... но тогда почти не имеем выгоды по сравнению с просто блочным
> чтением файла и переносом блоков

2 x CopyMemory vs 1 x MoveMemory
?

← →
DVM © (2013-05-08 10:11) [41]

> NoUser © (08.05.13 01:26) [39]

> Последовательно, кусками ~ 512MB [cViewSize] (+64KB для
> 1-го добавочного байта) начиная с последнего куска

А теперь поглядим в [31] и видим попытку смаппировать 4 гб (файл то у нас именно такого размера) целиком. Речь именно об этом была. Про маппирование кусками все знают и я об этом написал.

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

Ты все путаешь. Причем тут физическая память? Забудь о ней, нет ее для нас. Рассуждай логически. Мы хотим смаппировать скажем 2 гб файл. Но у нас в виртуальном адресном пространстве нет свободного блока 2 гб, т.к оно представляет скажем собой решето из занятых и свободных блоков, хотя в сумме там может и есть свободных 2 гб.
Все!!! Приехали. Маппировать некуда. Нельзя смаппировать файл частью в один блок частью в другой и потом обращаться ко всему(!!!) файлу по одному единственному указателю как к непрерывному блоку памяти. Разве это не очевидно.

> 2 x CopyMemory vs 1 x MoveMemory
> ?

Ловля блох по сравнению со скоростью записи на диск, которая в тысячи раз меньше все равно, чем копирование памяти. Я потому и написал ПОЧТИ НЕ БУДЕТ ВЫГОДЫ.

← →
DVM © (2013-05-08 10:25) [42]

> asail © (07.05.13 23:34) [37]

> FlushViewOfFile(pView, dwFileSize);
> не произойдет все та же перезапись всех 4х гигабайт + 1
> байт на диск? И в чем тогда выигрыш по сравнению со страничным/блочным
> переносом?

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

← →
NoUser © (2013-05-08 11:37) [43]

> Ну и разумеется для 4 гб надо 64 бит систему и 64 бит программу
Зачем же так категорично.

> Ты все путаешь. Причем тут физическая память?
Ну, извини, думал ты что-то не понял, вот и объяснился, а поискать виртуальных 0,5G в начале работы программы не должно быть проблемой.

> В маппировании файлов никакого волшебства нет
Это да.

← →
DVM © (2013-05-08 11:51) [44]

> NoUser © (08.05.13 11:37) [43]

> > Ну и разумеется для 4 гб надо 64 бит систему и 64 бит
> программу
> Зачем же так категорично.

Код из [31] при 4 гб файле только в 64 бит программе отработает нормально. Я ж только про это. Теоретически 32 бит программа в 64 бит системе сможет выделить около 4 гб со скрипом, но это крайний случай, получится редко.

А так кусками как ты уже сам сказал маппируй хоть терабайты в 32 бит программе.

← →
robt2 (2013-05-10 21:17) [45]

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

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

> и вообще без компа, плмку прошить под нужную задачку
Чем шить то будете ? :)

Чисто теоретический вопрос на запись в файл в начало со сдвигом Найти похожие ветки