Const Массив

← →
K-one (2009-11-17 00:38) [0]

Привет.

Имеется длинный массив (строка + числа в каждой ячейке), который должен находится в exe. Использоватся будет редко.
Как лучше его положить, в const или заполнять как только он понадобится?
Если положить в const будет ли он находится в памяти (насколько я помню нет) программы?

← →
antonn © (2009-11-17 00:40) [1]

я бы запихнул его в tmemorystream. А до запихивания прикрепил бы ресурсом к ехе, предварительно сжав zlib"ом (ну и при доставании распаковал бы).

← →
DVM © (2009-11-17 00:42) [2]

> Имеется длинный массив

насколько длинный? Строки какой длинны?

← →
K-one (2009-11-17 00:43) [3]

> А до запихивания прикрепил бы ресурсом к ехе, предварительно
> сжав zlib"ом (ну и при доставании распаковал бы).

Ну он не такой большой как вам показалось. килобайт 15.

← →
K-one (2009-11-17 00:44) [4]

Строки по макс 15 символов. и пару чисел байтовых в каждой ячейке

← →
antonn © (2009-11-17 00:44) [5]

я даже картинки в 10кб пакую. Как минимум чтобы труднее было спереть и отредактировать =)

← →
DVM © (2009-11-17 00:45) [6]

> килобайт 15.

плюнь, храни как обычно. 15 кбайт это мизер.

← →
K-one (2009-11-17 00:45) [7]

> я даже картинки в 10кб пакую.

Смысла нет.

← →
DVM © (2009-11-17 00:45) [8]

> antonn © (17.11.09 00:44) [5]
> я даже картинки в 10кб пакую. Как минимум чтобы труднее
> было спереть и отредактировать =)

неуловимый джо?

← →
K-one (2009-11-17 00:46) [9]

> DVM © (17.11.09 00:45) [6]
>
>
> > килобайт 15.
>
> плюнь, храни как обычно. 15 кбайт это мизер

дык я и собираюсь хранить как обычно. Просто вот спрашиваю если сохраню как const массив, он будет в памяти висеть при запуске проги, или читаться с образа? Кажись второе.

← →
DVM © (2009-11-17 00:47) [10]

> Просто вот спрашиваю если сохраню как const массив

пример приведи как ты его собираешься хранить. В каком месте этот массив будет располагаться?

← →
K-one (2009-11-17 00:50) [11]

> пример приведи как ты его собираешься хранить.

const
DefArray : array [0..xx] of TMyStatus = (
(Str: "mystring"; Ar1: 1; Ar2: 2);
(Str: "mystring"; Ar1: 1; Ar2: 2);
(Str: "mystring"; Ar1: 1; Ar2: 2);
...
)

← →
antonn © (2009-11-17 00:50) [12]

> неуловимый джо?

на самом деле все проще - все используемые ресурсы я храню в отдельной секции ресурсов, и доступ к ним осуществляет специальный класс, который по имени достанет файл, разожмет и отдаст запросившему (плюс кеширование если надо). Причем имя может содержать часть пути, т.е. "image\1.gif", файл может быть на диске, а может его и не быть, во втором случае программа его возьмет "из нутрей" :)

← →
K-one (2009-11-17 00:51) [13]

> В каком месте этот массив будет располагаться?

В const юнита

← →
DVM © (2009-11-17 00:59) [14]

> K-one (17.11.09 00:51) [13]

> В const юнита

Имхо он будет загружен в оперативную память и будет там висеть.

← →
K-one (2009-11-17 01:03) [15]

> Имхо он будет загружен в оперативную память и будет там
> висеть.

По моему нет. Он читает с образа exe. Короче пытаюсь искать.

← →
DVM © (2009-11-17 01:20) [16]

> K-one (17.11.09 01:03) [15]

> По моему нет.

в памяти он в памяти точно.

← →
K-one (2009-11-17 01:44) [17]

Вообще да в памяти, не динамической, в сегменте данных .

← →
oxffff © (2009-11-17 08:44) [18]

> K-one (17.11.09 00:50) [11]
>
> > пример приведи как ты его собираешься хранить.
>
>
> const
> DefArray : array [0..xx] of TMyStatus = (
> (Str: "mystring"; Ar1: 1; Ar2: 2);
> (Str: "mystring"; Ar1: 1; Ar2: 2);
> (Str: "mystring"; Ar1: 1; Ar2: 2);
> ...
> )

Это у тебя что имена пользователей и ключи шифрования?

← →
Дмитрий С © (2009-11-17 09:47) [19]

> oxffff © (17.11.09 08:44) [18]

Скорее статусы и что-то вроде ImageIndex-ы :)

← →
Leonid Troyanovsky © (2009-11-17 11:55) [20]

> K-one (17.11.09 00:38)

> Как лучше его положить, в const или заполнять как только
> он понадобится?

IMHO, строки в ресурс, скажем, STRINGTABLE, а
все остальное в - const.
Т.е., будет (IdentMystring, Ar1, Ar2),
а для получения строки - LoadStr*.

--
Regards, LVT.

← →
Кто б сомневался © (2009-11-17 14:19) [21]

Тоже вариант. Но STRINGTABLE тоже грузится в память. Вообще если подумать, то почти весь образ грузится в память. Если смысл в переносе в строк в ресурсы..?

← →
Leonid Troyanovsky © (2009-11-17 14:44) [22]

> Кто б сомневался © (17.11.09 14:19) [21]

> Тоже вариант. Но STRINGTABLE тоже грузится в память. Вообще
> если подумать, то почти весь образ грузится в память. Если
> смысл в переносе в строк в ресурсы..?

Переносить строки в ресурсы смысл есть. Например, для локализации.
В память же строки грузятся путем LoadString.

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

--
Regards, LVT.

← →
Игорь Шевченко © (2009-11-17 15:00) [23]

> Но STRINGTABLE тоже грузится в память

не грузится

← →
Кто б сомневался © (2009-11-17 16:35) [24]

> Игорь Шевченко © (17.11.09 15:00) [23]
>
>
> > Но STRINGTABLE тоже грузится в память
>
>
> не грузится

Т.е. вы хотите сказать что если обратится к строке в ресурсах, то windows будет опять обращатся к диску, и читать с диска?

← →
Игорь Шевченко © (2009-11-17 16:43) [25]

Кто б сомневался © (17.11.09 16:35) [24]

Первый раз да

← →
Кто б сомневался © (2009-11-17 17:01) [26]

> Первый раз да

А как же предварительное кэширование exe образа, если он небольшой?
Также если запустить со съемного носителя программу - она сможет работать без носителя.

← →
Игорь Шевченко © (2009-11-17 17:08) [27]

Кто б сомневался © (17.11.09 17:01) [26]

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

← →
Кто б сомневался © (2009-11-17 17:16) [28]

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

Здесь еще зависит от размеров оп. памяти, тот же диспетчер кэша подстраивается берет процент от общей памяти.
Я вот сейчас смотрю Руссиновича, он пишет

При первой операции ввода-вывода (чтения или записи) над файлом диспетчер кэша проецирует на свободный слот адресного пространства системного кэша 256-килобайтное представление области файла, выровненной по границе 256 Кб и содержащей запрошенные данные. Например, если из файла считывается 10 байтов по смещению 300 000 байтов от его начала, то проецируемое представление будет начинаться со смещения 262 144 (вторая область файла, выровненная по границе 256 Кб) и займет 256 Кб.

Также, в следующих версиях Windows наверняка это увеличено. Если exe небольшой под 1 -3 mb то скорее всего он весь кэшируется, я помню это где то читал, вот ищу.
Понятно что если это exe архив на 4 гига, то нет смысла этого делать.

Кто б сомневался © (17.11.09 17:16) [28]

Загрузчик не читает исполняемые файлы, ты не ту главу у Руссиновича читаешь, он их в память проецирует.

Потратил 40 минут, так и не нашел что делает реально система с вирт. памятью при старте процесса. Игорь подскажите где вы это вычитали?

Я где то читал что если возможно загрузить образ exe полностью в память, он будет загружен. и скорее всего так и делается, т.к. при старте exe и последующей с ним работе диск не мигает .
Надо попробовать глянуть на счетчики и на filemon - обращается ли к диску или нет. Уверен что нет.

> диск не мигает .

Индикатор всмысле.

Кто б сомневался © (17.11.09 18:10) [30]

Во-первых, у Рихтера, "Windows для профессионалов", 4-е издание, глава 20.
Во-вторых, была статья в MSDN Magazine: "Russell Osterlund: What Goes On Inside Windows 2000: Solving the Mysteries of the Loader. MSDN Magazine, March 2002"
В-третьих, в сигнальном номере MSDN Magazine Russion Edition была статья Соломона и Руссиновича о нововведениях в Windows XP, где рассказывалось про механизм Prefetch
В-четвертых, в описании диспетчера памяти у Соломона и Руссиновича в книжке про внутреннее устройство Windows

Сгенерил stringtable на 28 килобайт и 70 строк..
Добавил в свой реальный проект, размер 2,6 мб. В проекте создается только главная форма, и ничего более не делается.
Вывел отедльно кнопку с чтение строк через LoadString
Добавил счетчик Logical Disk F\Disk read bytes
Запустил. - счетчик показал.
Нажал на кнопку - все по нулям.
Закрыл программу, пошел перекурил (5 мин) - запустил програмуу - при запуске счетчик опять на нуле, что означает что образ был закеширован.

Что не так сделал?

XP x64. 4 гб ОЗУ. Всего включено 8 служб.

> Что не так сделал?

вот это.

> Добавил счетчик Logical Disk F\Disk read bytes

загрузка строк из ресурса - это операция страничного обмена

> загрузка строк из ресурса - это операция страничного обмена

Давайте упростим. Есть диск, а есть ОЗУ - вот у меня отключен своп - поэтому это моя ситуация.

В моем случае - при запуске программы exe образ кэшируется в ОЗУ - неважно как, но он уже там. Это показано на практике.
Мы спорили будут ли ресурсы exe читатся с диска только при первом запросе к ним, или образ будет сразу закеширован.
У меня получилось второе, первое не получается.

> В моем случае - при запуске программы exe образ кэшируется
> в ОЗУ - неважно как, но он уже там. Это показано на практике.
>

на какой практике, если не секрет ?

> Кто б сомневался © (17.11.09 19:13) [37]

> Мы спорили будут ли ресурсы exe читатся с диска только при
> первом запросе к ним, или образ будет сразу закеширован.

Про первый мы не спорили, т.е., доказывай.

--
Regards, LVT.

Я напомню с чего все началось.
Был задан вопрос, есть ли разница если строки будут добавлены как const или как ресурсы в плане загрузки в память.
Я говорю что особой нет, т.к. так или иначе образ будет закеширован почти полностью при старте (если он небольшой конечно).
Что и привел на примере 34.

Если я в чем то ошибся, то объясните мне Игорь в чем конкретно, без этого троллизма.

Const Массив Найти похожие ветки