MaPro

[serjvologda]

нифигасебе exeшник вырос до 8 метров посравнению со старой (0.4)..........

Вирусов добавил, чтобы скучно небыло

Кстати в не сжатом виде он 32Мб..

да.... много графики пихнул туда... ... а чем ты его в этот раз зжал у тебя прямо какая то мания шифрования кода что втой версии что в этой даже линки не подправить((
а я думал чем меньше и проше исходный код тем быстрее программа ? или безразницы что 0,4 мб что 32 мб экзэшник это наскорость не влияет ?
старая версия занимала в памяти около 4 метров при размере на винте 400 кб, а новая в памяти сразуже при запуске выделяет себе 70 метров
это как то влияет на саму программу и на ее скорость?
оч.интересно........ просто я в этом несилён.....

[Alexander]

да.... много графики пихнул туда... ... а чем ты его в этот раз зжал у тебя прямо какая то мания шифрования кода что втой версии что в этой даже линки не подправить(( а я думал чем меньше и проше исходный код тем быстрее программа ? или безразницы что 0,4 мб что 32 мб экзэшник это наскорость не влияет ? старая версия занимала в памяти около 4 метров при размере на винте 400 кб, а новая в памяти сразуже при запуске выделяет себе 70 метров это как то влияет на саму программу и на ее скорость? оч.интересно........ просто я в этом несилён.....

Графики не то чтобы много, только она во многоразмерных ico. Сжал тем же чем и предыдущие версии (400кб это тоже сжатый объём, сам экзешник MaPro никогда не занимал меньше 1Мб). Размер и степень сжатия экзешника виляет только скорость загрузки программы в оперативку, сейчас она занимает 70Мб, половина это графика. Размер исходного кода никак не влияет на скорость работы программы, ибо RAM незря так называется (Random Access Memory) =), влияет только на место в оперативке. (есть теоритически возможность грузить не весь распакованный экзешник в память, тогда влияло бы). Т.е. едиственный минус сейчас что больше оперативки кушает. Графику собираюсь перевести на png, тогда и объём упадёт в раза 2-3.

[serjvologda]

да.... много графики пихнул туда... ... а чем ты его в этот раз зжал у тебя прямо какая то мания шифрования кода что втой версии что в этой даже линки не подправить(( а я думал чем меньше и проше исходный код тем быстрее программа ? или безразницы что 0,4 мб что 32 мб экзэшник это наскорость не влияет ? старая версия занимала в памяти около 4 метров при размере на винте 400 кб, а новая в памяти сразуже при запуске выделяет себе 70 метров это как то влияет на саму программу и на ее скорость? оч.интересно........ просто я в этом несилён.....

Графики не то чтобы много, только она во многоразмерных ico. Сжал тем же чем и предыдущие версии (400кб это тоже сжатый объём, сам экзешник MaPro никогда не занимал меньше 1Мб). Размер и степень сжатия экзешника виляет только скорость загрузки программы в оперативку, сейчас она занимает 70Мб, половина это графика. Размер исходного кода никак не влияет на скорость работы программы, ибо RAM незря так называется (Random Access Memory) =), влияет только на место в оперативке. (есть теоритически возможность грузить не весь распакованный экзешник в память, тогда влияло бы). Т.е. едиственный минус сейчас что больше оперативки кушает. Графику собираюсь перевести на png, тогда и объём упадёт в раза 2-3.

всё понятно. главное что бы насаму прогу не влияло)))))

[Alexander]

Написал основу для модуля индексирования наличия тайлов, получилось сравнительно неплохо, но хуже чем ожидалось.
Провёл несколько тестов (имеющих малое отношение к реальности), но достаточно показательных, потому как привело к работе модуля в наиболее худших условиях чем получится на практике.
Тест имел следующий вид:
procedure TestTree;
var
i: Integer;
c: Int64;
t: TIndexTree;
begin
Randomize;
t:= TIndexTree.Create;
Logger.addMessage('Заполнение начато');
for i := 0 to 1000000 do
begin
t.setExists(Random(MaxInt));
end;
Logger.addMessage('Заполнение оконченно');
Logger.addMessage('Сканирование начато');
c:= 0;
for i := 0 to MaxInt do
begin
if (t.isExists(i)) then inc(c);
end;
Logger.addMessage('Сканирование законченно');
Logger.addMessage('Всего существует: ' + IntToStr(t.existsCount));
Logger.addMessage('Использовано памяти: ' + IntToStr(t.usedMemory));
end;

Вначале дерево заполнялось случайным наличием чисел в количестве 1000001 наличий [использовался промежуток от 0 до 2147483646] (числами у меня индексируются тайлы, число формируется из x,y,z,type).
Потом проходило сканирование от 0 до MaxInt [0..2147483647] на наличие тайлов.
Далее встроенная функция подсчёта количества имеющихся тайлов.
Далее встроенная функция подсчёта объёма используемой памяти. (не нужно думать что в реальных условиях использовался бы тот же объём памяти, ведь тайлы качаются пачками, а не хаотично).

Результаты последнего теста:
0:20:46.001 31.12.2008 (среда) : Заполнение начато
0:20:47.291 31.12.2008 (среда) : Заполнение оконченно
0:20:47.291 31.12.2008 (среда) : Сканирование начато
0:35:14.579 31.12.2008 (среда) : Сканирование законченно
0:36:17.007 31.12.2008 (среда) : Всего существует: 999882
0:36:17.014 31.12.2008 (среда) : Использовано памяти: 537706819

К сожалению случайное заполнение использовало все отведённые блоки и было использовано около 500Мб памяти (во всех тестах при количестве тайлов 1000001), а также наличие всех блоков обрекло систему проверять все уровни дерева при каждой проверки, но результат всёравно неплох.
За 14,5 минут было произведено 2147483648 проверок, что соответствует всреднем 2468372 проверке в секунду. А значит что построение карты заполнения на 8 уровней ниже на моём мониторе займёт чуть больше 0,5 секунды.

Жалко что нет возможности сравнить с той индексирующей структурой что в базах беркли.

[svp]

Alexander
Не планируете сделать dll-ку для работы с Вашим индексом?
Удобно было бы иметь следующие функции АПИ:
1. Добавить/Удалить тайл (x, y, z, type, ver, quality). В крайнем случае можно без ver и
2. Проверить наличие тайла
quality.
Желательно:
3. Добавить/удалить группу тайлов (массив записей (x, y, z, type, ver, quality)).
4. Проверить наличие группы файлов (на выходе битовое множество, поэлементно соответствующее входному массиву).

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

[Alexander]

Alexander
Не планируете сделать dll-ку для работы с Вашим индексом?
Удобно было бы иметь следующие функции АПИ:
1. Добавить/Удалить тайл (x, y, z, type, ver, quality). В крайнем случае можно без ver и
2. Проверить наличие тайла
quality.
Желательно:
3. Добавить/удалить группу тайлов (массив записей (x, y, z, type, ver, quality)).
4. Проверить наличие группы файлов (на выходе битовое множество, поэлементно соответствующее входному массиву).

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

Не планировал, но возможно если время появится.
Сейчас сильно загружен работой.
Да и существуют несколько странностей, толи в Delphi 2009 сильно перестарались, толи я раньше не сталкивался с подобным. Разве в Delphi объекты удаляются автоматически, когда на них все ссылки теряются? (может кто точно знает когда и при каких обстоятельствах)
Ещё и с dll надо разбираться, ибо не разу не делал.

[svp]

толи в Delphi 2009 сильно перестарались, толи я раньше не сталкивался с подобным. Разве в Delphi объекты удаляются автоматически, когда на них все ссылки теряются? (может кто точно знает когда и при каких обстоятельствах)

Смотря какие объекты и смотря как они были созданы. Если при создании компонента (TComponent) был указан его владелец, то владелец будет сам заботиться о его освобождении.
Или речь идёт об интерфейсах? Вообще как-то с 2009 не приходилось сталкиваться. Может там правда полностью перешли на интерфейсы. Вообще удобно, когда объект подсчитывает ссылки на себя и самоуничтожается когда ссылок не остаётся.

[Alexander]

Или речь идёт об интерфейсах?

Да, о них самых )

Конкретнее:

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

type
  IMemoryUser = interface(IInterface)
    ['{69856B39-CEC0-42F0-87EF-AE870FE20C0A}']
    procedure free;
  end;

  IIndexElementsIterator = interface(IMemoryUser)
    ['{E512EC2B-16A5-4F38-A320-F7EB0777CCAC}']
    procedure reset;
    function hasNext: boolean;
    function next: Int64;
  end;

  IIndexTreeElement = interface(IMemoryUser)
    ['{AA39ADC5-FB8B-4A9F-A6F3-87A5BA863222}']
    function isExists(number: int64): boolean;
    function isNotExists(number: int64): boolean;
    function isNotExistsOnServer(number: int64): boolean;
    procedure setExists(number: int64);
    procedure setNotExists(number: int64);
    procedure setNotExistsOnServer(number: int64);
    function existsCount: Int64;
    function notExistsOnServerCount: Int64;
    function usedMemory: Int64;
    procedure clear;
  end;

Объект:

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

type
  TIndexTreeElement = class(TInterfacedObject, IIndexTreeElement)
  private
    m_elements: TIndexElementsArray;
    m_level: TTreeLevel;
    m_iCoef: Int64;
    m_iFirst: Int64;
    constructor Create(first: Int64; coef: Int64; level: TTreeLevel);
    function getSubTree(number: Int64; cr: boolean): IIndexTreeElement;
  public
    destructor Destroy; override;
    function isExists(number: Int64): boolean;
    function isNotExists(number: Int64): boolean;
    function isNotExistsOnServer(number: Int64): boolean;
    procedure setExists(number: Int64);
    procedure setNotExists(number: Int64);
    procedure setNotExistsOnServer(number: Int64);
    function existsCount: Int64;
    function notExistsOnServerCount: Int64;
    function usedMemory: Int64;
    procedure clear;
    procedure free;
  end; 

Создаётся так:

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

function TIndexTreeElement.getSubTree(number: Int64; cr: boolean): IIndexTreeElement;
var
  bl: word;
  f: Int64;
begin
  if Self = nil then raise MPEIllegalSelfState.Create
    ('TIndexTreeElement.getSubTree: Self is nil');
  bl:= (number div m_iCoef) mod ElementsCount;
  if (m_elements[bl] = nil) and cr then
  begin
    f:= m_iFirst + m_iCoef * bl;
    case m_Level of
      0: m_elements[bl]:= TIndexTreeElement.Create(f, Level1Coef, 1);
      1: m_elements[bl]:= TIndexTreeElement.Create(f, Level2Coef, 2);
      2: m_elements[bl]:= TIndexTreeElement.Create(f, Level3Coef, 3);
      3: m_elements[bl]:= TIndexBitArray.Create(f);
    end;
  end;
  Result:= m_elements[bl];
end;

методы раньше были написаны так:

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

procedure TIndexTreeElement.free;
begin
  if Self <> nil then Self.Destroy;
end;

destructor TIndexTreeElement.Destroy;
begin
  Self.Clear;
  inherited;
end;

procedure TIndexTreeElement.clear;
var i: Integer;
begin
  if Self = nil then exit;
  for i := 0 to ElementsCount - 1 do
  begin
    if m_elements[i] <> nil then
      m_elements[i].free;
  end;
end;

и при попытке вызвать free на всё дерево при работе через интерфейс вылетал как водится 'отказ в доступе к памяти', если избывиться от интерфейсов всё отлично отрабатывало, если не избавляться и не вызывать free то при занулении ссылке на дерево память высвобождается.
Раньше обходился без интерфейсов, поэтому и не разбирался в их подробностях в дельфи (думаю это справедливо и для более ранних версий чем 2009).
Мне нужно знать подробности чтобы спроектировать так чтобы исключить утечку памяти.
Избавление от интерфейсов не выход, т.к. появляются лишние проверки.

[Alexander]

Забыл написать что 'отказ в доступе' вылетал как я предпологаю(смотрел через дебагер и сделал выводы), что уничтожался интерфейс, а не объект, при первом же вызове Destroy.

[vdemidov]

Так даже в седьмой делфе интерфейсы подсчитывали ссыкли и уничтожались. Достаточно переменную типа IIndexTreeElement со сылкой на интерфейс присвоить nil и объект будет удален.