freepascal.ru

runewalsh писал(а):RESET'нутые страницы переиспользуют другие приложения без необходимости системе выгружать в своп их старое содержимое.

я смею предположить, что в этих страницах хранятся особые данные.
А точнее какие-нить битмапы, ну или структуры, которые никуда не ссылаются кроме, как на самих себя.

Например, если хранить в такой вот страничке ссылку на Паскаль объект, который создаётся run-time менеджером памяти; то после RESET_UNDO, совсем не факт, что ссылка на объект будет валидной. Ведь сам FreeMem обратного хода не имеет. (в отличии от того же VirtualAlloc)

runewalsh писал(а):Если RESET_UNDO сработал, мы можем не читать их из файла, тем самым экономя время и I/O.

а были ли такие тесты: сделали ли SSD диски эту оптимизацию бесполезной? (спрашиваю для расширения кругозора считают использвание фичи RESET_UNDO вполне себе адекватным решением)

Будет бесполезной, но это не только ради пропуска чтения с диска, ещё твой процесс будет занимать меньше памяти, а освобождаемые и выделяемые снова страницы система ЗАНУЛЯЕТ перед переиспользованием, как по контракту VirtualAlloc, так и потому, что они могли принадлежать другому процессу.

Нет ничего СЛИШКОМ УЖ ужасного в том, чтобы сохранить во (временный и актуальный в рамках 1 процесса) файл указатель, а потом прочитать его назад. Но да, проще сохранять туда только тяжёлые данные — собственно картинки и их части, тем более остальные структуры в сравнении с ними не занимают ничего и с ними можно работать по-нормальному. Это можно оформить как отдельный интерфейс для манипуляций с памятью под картинки.

runewalsh писал(а):Но да, проще сохранять туда только тяжёлые данные — собственно картинки и их части, тем более остальные структуры в сравнении с ними не занимают ничего и с ними можно работать по-нормальному. Это можно оформить как отдельный интерфейс для манипуляций с памятью под картинки.

вот в этот момент, следует выложить ссылку на редактор.
даже если он коммерческий, и написан на крестах!

Я этого не видел лично, так, примерно почувствовал.
Гуглится libsai — реверс-инжиниринг формата Paint Tool SAI, там структура выглядит оптимизированной как раз под эти все штуки, в частности, картинки бьются на блоки 32×32, потому что 32×32×RGBA8 = 4 Кб.

Вообще-то такое в программировании называют "использование грязного хака". И эти грабли, почти неизбежно, однажды бьют по лбу...

Снег Север писал(а):Вообще-то такое в программировании называют "использование грязного хака".

если ты про RESET_UNDO, то это заявленный операционкой функционал.

Снег Север писал(а):"использование грязного хака" И эти грабли, почти неизбежно, однажды бьют по лбу...

Cheb очень любит эти дела )))

Продолжим. Больше для понимания, что всё верно делаю, а то что-то голова иногда не варит, а инет не помогает полностью. )))

Работаю со строками. SetLength - устанавливаю длину строки, мне ведь её не надо в конце обязательно в нуль устанавливать? Или всё же надо?

Если строка не уходит из зоны видимости компилятора - ненадо.

zub, благодарю! А есть информация поподробнее? Ни где ни чего по данному поводу вообще найти не могу. Просто даже не ссылаются на очистку строк/строковых переменных.

хз куда еще подробнее? По сути SetLength с точки зрения выделения памяти ничем не отличается от присвоения переменной какогото значения.

Код: Выделить всё

var
  s:ansistring;
begin
  SetLength(s,1);//можешь считать это как s:=inttostr(random(255)); - выделил память под 1 знак, но там пока "мусор" лежит
  //s:='';//"развыделил" память обратно, но это за тебя компилятор cделает в end
end;

zub, нет ))), не это меня интересует. А именно по освобождению памяти от стоковых переменных. Есть где и что написано? На любом языке и на любом ЯП. )))

В начале процедуры компилятор сам инициализирует (зануляет) стековые управляемые переменные, а в конце — сам финализирует, вставляя неявный try-finally:

Код: Выделить всё

var
   s: ansistring;
begin
   Initialize(s); // делает pointer(s) := nil
   try
      // пользовательский код
      SetLength(s, 1);
      // конец пользовательского кода
   finally
      Finalize(s); // делает fpc_ansistr_dec_ref(s); pointer(s) := nil
   end;
end;

Для new'нутых записей или Create'нутых классов Initialize/Finalize тоже автоматически вставляются в моменты создания (new или Create) и уничтожения (dispose или Destroy). Самому за этим нужно следить, только если ты решил поизвращаться с размещением объектов в памяти, но тебе рано о таком задумываться. Например, я люблю классы, которые представляют собой неизменяемый список чего-то, выделять одним махом вместе с данными самого списка (часто не одного): GetMem(MyClass.InstanceSize + n * sizeof(ItemSize)), но после этого всё слежение за управляемыми типами перекладывается на твои плечи: нужно руками вызвать MyClass.InitInstance, InitializeArray(ItemsPtr, TypeInfo(MyItem), n) при создании и FinalizeArray(ItemsPtr, TypeInfo(MyItem), n) при уничтожении.

К управляемым переменным относятся длинные строки (ansistring/widestring/unicodestring), динамические массивы (array of T) и интерфейсные ссылки (interface). Простые указатели (^type) или классы не относятся, то есть их нужно dispose'ать или Destroy'ить вручную.

runewalsh, благодарю, но почти ни чего нового. ))) В данный момент времени, меня заинтересовали именно строки. Потому что мне надо точно знать, что они очистятся, при каких-то моих производимых с ними действиях.

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

Хотя бы куда копнуть, чтоб добраться до этой информации? )))

Разные компиляторы (или, по крайней мере, языки) творят разные вещи, твой вопрос либо имеет смысл в контексте (Free) Pascal, и тогда исчерпывающий ответ на него заключается именно в том, в чём для тебя «ничего нового не было», либо он не имеет смысла изначально. К тому же, как правило, динамически создаваемые «строки» в плане работы с памятью не отличаются от других динамических объектов (тех же массивов), так что странно именно на них делать акцент.

Не менее странно говорить про «закрытие программы». Как говорилось выше, строки освобождаются при выходе из области видимости: стековые — при выходе из ПРОЦЕДУРЫ (не программы, блин), в составе другого объекта — при уничтожении этого объекта. Строки в глобальных переменных — да, будут уничтожены при «закрытии программы», но и это не потому, что они «именно строки», а потому, что они managed-типы, которые и задуманы, чтобы, в качестве глобальных переменных, финализироваться на выходе из программы, точно таким же образом, как локальные управляемые переменные финализируются на выходе из процедуры.

Раз ничего нового не было, то и не будет, ты ищешь в тёмной комнате чёрную кошку, которой там нет.

С

runewalsh писал(а):Раз ничего нового не было, то и не будет, ты ищешь в тёмной комнате чёрную кошку, которой там нет.

Совершенно верно, насколько я знаю все современные программы используют "линейную память " выделяемую в виртуальном адресном пространстве и все что программа с ним вытворяет никак не влияет на то, как эта память будет использоваться после закрытия программы. (Можно СПЕЦИАЛЬНО затребовать у систем выделить отдельную область но и она скорее всего автоматически будет "снята с довольствия " после закрытия программы )