Помогите с оптимизацией.

← →
Riply © (2007-10-16 22:04) [0]

Здравствуйте !
Вот решила чуть-чуть заняться "ловлей блох":
(Ну очень не хватает типа в полтора DWord`a или три четверти Int64 :)

type PTHREE_QOART = ^THREE_QOART; THREE_QOART = packed record QuartLow: DWord; QuartHigh: Word; procedure SetQuart(const pValue: PULargeInteger); inline; function GetQuart: Int64; end; procedure THREE_QOART.SetQuart(const pValue: PULargeInteger); begin if pValue <> nil then with pValue^ do begin QuartLow := LowPart; QuartHigh := HighPart; end else begin QuartLow := 0; QuartHigh := 0; end; end; function THREE_QOART.GetQuart: Int64; begin Result := Int64(QuartHigh) shl 32 or QuartLow; end;
Помогите мне в этом благородном занятии (ловле) и подскажите
как бы все это дело "оптимизировать" ?

P.S.
Вариант оптимизации через выбрасывание дури из головы,
тоже будет принят к рассмотрению :)

← →
begin...end © (2007-10-16 22:19) [1]

function THREE_QOART.GetQuart: Int64;
begin
with Int64Rec(Result) do
begin
Lo := QuartLow;
Hi := QuartHigh
end
end

← →
guav © (2007-10-16 23:35) [2]

Используй FILE_REFERENCE целиком, это будет как раз Int64.
Если зачем-то нужно будет нужна часть, которая индекс, то тогда её можно будет определить как ref and $FFFFFFFFFFFF.

← →
Riply © (2007-10-17 00:22) [3]

>[1] begin...end © (16.10.07 22:19)
Спасибо.
Приступила к включению THREE_QOART в работу и тут же понадобились
еще две функции:
function THREE_QOART.Is_MAX_QUART: Boolean;
begin
Result := (QuartLow = MAXDWORD) and (QuartHigh = MAXWORD);
end;

function THREE_QOART.Is_NULL: Boolean;
begin
Result := (QuartLow = 0) and (QuartHigh = 0);
end;

> [2] guav © (16.10.07 23:35)
> Используй FILE_REFERENCE целиком, это будет как раз Int64.
Привет !
FILE_REFERENCE то я использую вовсю. Куда ж без него ? :)
Но это, когда идет "внутренняя" работа.
А когда речь заходит о предоставлении пользователю полученных
данных (в удобном для него виде), да еще и с возможностью над ними изголяться как ему вздумается,
вот тогда и задумаешся о размере единицы информации. А там уже таким вещам как FILE_REFERENCE
не место. Слишком расточительно использовать весь Int64,
где можно обойтись тремя четвертями - как никак аж целых два байта экономии :)
Плюс к этому, чисто визуальное удобство, когда используется в других разных структурах.
Сразу все видно и понято зачем так сделано :) Все это imho, разумеется.

← →
Riply © (2007-10-17 00:59) [4]

>[3] Riply © (17.10.07 00:22)
Весь сыр-бор разгорелся из-за попытки
как-то определить следующие структуры:
type _QUERY_HEADER = record OffsetNextEntry : Word; ObjAttributes : Word; ObjNameLength : Word; end; _QUERY_STREAM = packed record // QUERY_HEADER ObjSize : THREE_QOART; ObjName : array[0..0] of Byte; end; _QUERY_FILE = packed record // QUERY_HEADER OffsetFirstStream : DWord; ObjSize : THREE_QOART; ObjName : array[0..0] of Byte; end; _QUERY_DIRECTORY = packed record // QUERY_HEADER OffsetFirstChild : DWord; OffsetFirstStream : DWord; ObjName : array[0..0] of Byte; end; _NAMED_QUERY_OBJECT = packed record OffsetNextEntry : Word; ObjAttributes : Word; ObjNameLength : Word; case integer of 0: (ObjStream: _QUERY_STREAM); 1: (ObjFile: _QUERY_FILE); 2: (ObjDir: _QUERY_DIRECTORY); end;

Разумеется размер NAMED_QUERY_OBJECT для сохранения
будет вычисляться в зависимости от ObjAttributes.
Хочеться быстро делать следующее:
Последовательно заполнить выделенный блок памяти NAMED_QUERY_OBJECT - ми
записывая, каждый новый в конец предыдущего.
Преобразовать этот блок в индексированную структуру.
(к ней еще есть требования, но пока не важно).
Вот и пытаюсь сделать что-то маленькое и простое :)

← →
ANTPro © (2007-10-17 01:28) [5]

> [4] Riply © (17.10.07 00:59)
> : array[0&#1330]

Можно рассказать смысл сего выражения, что-то часто встречаю, но описания пока не видел :(

← →
ANTPro © (2007-10-17 01:30) [6]

> [4] Riply © (17.10.07 00:59)
> : array[0..0]

Галочка типографировать вредная штука :/

← →
guav © (2007-10-17 01:36) [7]

И всё-таки, почему не использовать Int64 вместо THREE_QOART ?

← →
Zeqfreed © (2007-10-17 01:40) [8]

> ANTPro © (17.10.07 01:28) [5]

Чтобы можно было использовать компактный синтаксис для доступа к данным по индексу.

← →
Riply © (2007-10-17 02:14) [9]

> [7] guav © (17.10.07 01:36)
> И всё-таки, почему не использовать Int64 вместо THREE_QOART ?
Допустим нам надо получить "список" потоков.
Размер каждой записи о потоке будет вычисляться примерно так:
SizeOf(_QUERY_HEADER) + SizeOf(_QUERY_STREAM) - SizeOf(Byte) + ObjNameLength
Как ты знаешь, потоков гораздо больше, чем директорий + файлов.
При использовании Int64 вместо THREE_QOART, у нас размер каждого кирпичика записи
увеличивается на два байта. А при, допустим, миллионе потоков (что для диска совсем не много)
это два мегабайта памяти. Аналогично и с файлами.

> [5] ANTPro © (17.10.07 01:28)
См. [8] Zeqfreed © (17.10.07 01:40)
И еще эта запись с "изменяющимся размером". Играет роль поле OffsetNextEntry.
Очень некузяво сказала, но не знаю как по-другому.

← →
Riply © (2007-10-17 02:32) [10]

> [7] guav © (17.10.07 01:36)
> И всё-таки, почему не использовать Int64 вместо THREE_QOART ?

В догонку:
Не мне тебе рассказывать о способе
хранения UpdateSequenceArray в MULTI_SECTOR_HEADER :)
А ради чего ребята из Microsoft так поступают. Экономия идет чуть ли не на биты !
Так что мои выкрутасы это так... детский лепет по сравнению с мировой революцией :)

> Не мне тебе рассказывать о способе
> хранения UpdateSequenceArray в MULTI_SECTOR_HEADER :)

Не вижу там никакой экономии, там обычный массив.
Наверное ты про хранение структуры на которую указывает MappingPairsOffset. Так там же экономия большая, а не менее 20% как у тебя. Ну и цель там очевидна: чтобы как можно больше файлов вписались в один файлрекорд, т.е. для ускорения работы с файлами.
Причём заметь, на этом:
LONGLONG AllocatedLength; LONGLONG FileSize; LONGLONG ValidDataLength; LONGLONG TotalAllocated;
экономить не пытаются, хотя и твоим способом сэкономить было бы легко (в С есть битовые поля) и можно было бы воспользоваться тем, что значения обычно мало отличаются.

> При использовании Int64 вместо THREE_QOART, у нас размер
> каждого кирпичика записи
> увеличивается на два байта. А при, допустим, миллионе потоков
> (что для диска совсем не много)
> это два мегабайта памяти.

не храните все данные в памяти. Винчестер большой: пользуйтесь MMF.

>[11] guav © (17.10.07 09:42)
> Наверное ты про хранение структуры на которую указывает MappingPairsOffset.
Sorry. "Спутала с прямым углом". Но ты меня правильно понял :)

>Так там же экономия большая, а не менее 20% как у тебя.
Ну и что, что у меня маленькая. Не все же сразу. Пока пусть будет так.

>Ну и цель там очевидна: чтобы как можно больше файлов вписались в один файлрекорд,
>т.е. для ускорения работы с файлами.
У нас с ними цели совпадают. Чудеса да и только :)

>Причём заметь, на этом:
>LONGLONG AllocatedLength;
>......
>экономить не пытаются, хотя и твоим способом сэкономить
>было бы легко (в С есть битовые поля) и можно было бы воспользоваться тем,
>что значения обычно мало отличаются.
Они не пытаются экономить там, где идет описание отдельно взятого объекта.
Лежит он себе в рекорде и никого не трогает. Они только ссылаются на него.
(хотя, если посмотреть способ построения структуры для хранения этих описаний,
то попытки экономии видны сразу, и довольно успешные :)
А как только дело у них доходит до конструкции, содержащей список объектов(ссылок на объекты),
то тут начинается борьба "не на шутку" за каждый бит. :)

>[12] umbra © (17.10.07 10:15)
>не храните все данные в памяти. Винчестер большой: пользуйтесь MMF.
Хранить можно где угодно.
Но почему из наличия места должно следовать отсутствие
попыток его экономии (если эти попытки не связаны с большими затратами) ?

Помогите с оптимизацией. Найти похожие ветки