Пишу сортировщик текстовых файлов большого размера. Для чтения файла отвожу ему буфер размером 20 Метров. READ_BUFFER_SIZE equ 01400000h ; 20 Mb оперативки ReadBuff db READ_BUFFER_SIZE dup (?) Изврат конечно, но explorer.exe жрет примерно столько же, почему бы и нет? так вот я заметил, что длительность ассемблирования пропорциональна размеру буфера. То есть если его размер 1Mb - компилятор работает секунд 10, а если 20Mb - то повисает хрен знает на сколько - я так и не дождался. Я так чувствую, что компилятор пытается проэмулировать работу будущей программы и найти в ней ошибки. Или может еще чем занимается - х3. Может есть ключик (/Zs не спасет), чтобы компиляция проходила быстрее, или другой способ сберечь время? Почему-то очень не хочется выделять память динамически.
Известный баг. Нет смысла выделять статическую память такого большого размера. Используй динамическую память (VirtualAlloc).
может выделить этот буфер в отдельный *asm, скомпилировать единожды в *o, и потом просто компоновать с остальными модулями?
r90 Возможно, но мне показалось наиболее дешевым и сердитым использовать GlobalAlloc. Вот интересно, на много это замедлит сортировщик? Ведь в нем каждый такт дорог.
drmist А "статическая" память выделяется тем же VirtualAlloc. Точно так же и ты выдели 1 раз. А вот GlobalAlloc и правда может замедлить
А если вдруг понадобится буфер на 21 Мб? Опять полчаса компилировать объектник? )) имхо, самое разумное решение - virtualalloc. Да и GUI здесь по барабану.
