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 гига, то нет смысла этого делать.

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

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

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

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

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

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

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

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

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

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

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

Кто б сомневался © (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

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

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

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

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

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

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

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

вот это.

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

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

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

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

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

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

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

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

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

← →
Leonid Troyanovsky © (2009-11-17 21:59) [39]

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

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

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

--
Regards, LVT.

← →
Кто б сомневался © (2009-11-18 00:43) [40]

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

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

> Я говорю что особой нет, т.к. так или иначе образ будет
> закеширован почти полностью при старте (если он небольшой
> конечно).

Ты помести фильм на пару сотен мегабайт в ресурс и посмотри, как Windows обращается к диску...
И еще: у тебя антивирус стоит ? Если да, то он может весь файл при обращении к нему, включая ресурсы.

"The loader uses the memory-mapped file mechanism to map the appropriate pieces of the file into the virtual address space. To use a construction analogy, a PE file is like a prefabricated home. It"s essentially brought into place in one piece, followed by a small amount of work to wire it up to the rest of the world (that is, to connect it to its DLLs and so on). This same ease of loading applies to PE-format DLLs as well. Once the module has been loaded, Windows can effectively treat it like any other memory-mapped file"
http://msdn.microsoft.com/en-us/library/ms809762.aspx

> Ты помести фильм на пару сотен мегабайт в ресурс и посмотри,
> как Windows обращается к диску...

Я это уже говорил. что небольшие размером 3 мб и больше незнаю до скольки .

> И еще: у тебя антивирус стоит ? Если да, то он может весь
> файл при обращении к нему, включая ресурсы.

У меня запущено всего 8 служб. Из прог стоит только файрволл Outpost 4 в котором почти все отключено, кроме DNS и Резалка релкамы и детектора аттак. Я его вырубил для проверки, проверил еще раз - то же самое. Проверь у себя, возможно будут другие результаты.
Может это потому что у меня своп выключен.

> Кто б сомневался (18.11.2009 00:43:40) [40]

Разница, в общем случае есть, поскольку ресурсы будут подкачивать с диска, командой LoadString, а const просто ссылка на память, из сегмента CODE

> Кто б сомневался © (18.11.09 03:35) [42]

> Может это потому что у меня своп выключен.

Ресурсы мапятся только для чтения, т.е., в этой
части файл подкачки участия не принимает.

Разница будет со страницами данных на запись.

--
Regards, LVT.

> Разница, в общем случае есть, поскольку ресурсы будут подкачивать
> с диска, командой LoadString

Созал sfx архив на 16 mb - 7z. Перезагрузился.
Запустил, график показал, жму распаковку на другой диск, график на нуле.
Закрыл, открыл опять - график на нуле. Кэширование? Да, тут и спорить нет смысла.

> Ссылок тебе дадено - читай и воздастся

Я и раньше знал что файл проецируется. Но на деле получается что образ кэшируется почти полностью. Статьи статьями (кстати 8 летней давности), но ОС развивается, что то меняется, улучшается с сервис паками.

> Статьи статьями (кстати 8 летней давности), но ОС развивается,

Поэтому принимать за догму, свято веря не правильно мягко говоря.

> Игорь Шевченко © (18.11.09 01:33) [41]
http://msdn.microsoft.com/en-us/library/ms809762.aspx

March 1994 - уже прошло 16 лет.

> Кто б сомневался (19.11.2009 16:22:45) [45]

А речь не про диск, а про LoadString, диск естественно будет закеширован, но вызов функции не куда не денется.

Кто б сомневался © (19.11.09 19:10) [48]

Мягко говоря, тебе ссылок было дано не только в последнем моем посте, но и раньше. Читай и воздастся тебе.

Еще раз: исполняемый модуль всегда проецируется в адресное пространство процесса. Какие страницы и какое их количество коммитится (загружается с диска в рабочий набор процесса) при первом обращении к коду модуля - подробно пишет Руссинович, Остерлунд и так далее.
Страницы ресурсов при загрузке обычно не попадают в рабочий набор.

Судить по индикатору диска занятие более чем глупое, судить можно по Performance monitor, смотря показания page faults.

> А речь не про диск, а про LoadString, диск естественно будет
> закеширован, но вызов функции не куда не денется.

Можно поподробнее. Т.е. при старте exe образ кэшируется, вы это хотите сказать?

> Судить по индикатору диска занятие более чем глупое

Еще раз повторюсь. Был вопрос, кэшируется ли exe в память или читается с диска при первом запросе. В данном случае счетчик из Performance monitor под названием Local Disk четко показывает эту картину.
Идет обращение к диску или нет. У меня не идет, exe кэшируется при старте.
Я не пойму почему это по твоему "глупое занятие", если мне нужно узнать кол. обращений к диску?
Объясни конкретно, чтобы уже закрыть этот спор..

> или читается с диска при первом запросе

Имеется ввиду - "или ресурсы читаются с диска при первом запросе".
Если нет, то почему на практике получается иное?

Кто б сомневался © (19.11.09 20:43) [53]

> В данном случае счетчик из Performance monitor под названием
> Local Disk четко показывает эту картину.

В данном случае смотри счетчик page faults

> Был вопрос, кэшируется ли exe в память

Нет

> или читается с диска при первом запросе

По мере обращения к страницам exeшника (dll), они отображаются в рабочий набор процесса. Возможно кластерами, размер кластера зависит от кучи факторов, в том числе от типа носителя.

> Объясни конкретно

Рассказывай конкретно характеристики своей системы. Все.

> Кто б сомневался (19.11.2009 20:43:53) [53]

Ничего подобного я не говорил, закешировано будет 16 строк минимум, при загрузке одной строки. При том ты меняешь суть, вопрос был не про диск и прочее, а есть ли разница, разница есть на вызове функции.

> Кто б сомневался (19.11.2009 20:52:54) [54]

Работа с ресурсами очень оптимизирована.

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