Форум: "Начинающим";
Текущий архив: 2007.11.11;
Скачать: [xml.tar.bz2];
ВнизПомогите с оптимизацией. Найти похожие ветки
← →
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Բ]
Можно рассказать смысл сего выражения, что-то часто встречаю, но описания пока не видел :(
← →
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 так поступают. Экономия идет чуть ли не на биты !
Так что мои выкрутасы это так... детский лепет по сравнению с мировой революцией :)
← →
guav © (2007-10-17 09:42) [11]
> Не мне тебе рассказывать о способе
> хранения UpdateSequenceArray в MULTI_SECTOR_HEADER :)
Не вижу там никакой экономии, там обычный массив.
Наверное ты про хранение структуры на которую указывает MappingPairsOffset. Так там же экономия большая, а не менее 20% как у тебя. Ну и цель там очевидна: чтобы как можно больше файлов вписались в один файлрекорд, т.е. для ускорения работы с файлами.
Причём заметь, на этом:LONGLONG AllocatedLength;
LONGLONG FileSize;
LONGLONG ValidDataLength;
LONGLONG TotalAllocated;
экономить не пытаются, хотя и твоим способом сэкономить было бы легко (в С есть битовые поля) и можно было бы воспользоваться тем, что значения обычно мало отличаются.
← →
umbra © (2007-10-17 10:15) [12]
> При использовании Int64 вместо THREE_QOART, у нас размер
> каждого кирпичика записи
> увеличивается на два байта. А при, допустим, миллионе потоков
> (что для диска совсем не много)
> это два мегабайта памяти.
не храните все данные в памяти. Винчестер большой: пользуйтесь MMF.
← →
Riply © (2007-10-17 17:17) [13]>[11] guav © (17.10.07 09:42)
> Наверное ты про хранение структуры на которую указывает MappingPairsOffset.
Sorry. "Спутала с прямым углом". Но ты меня правильно понял :)
>Так там же экономия большая, а не менее 20% как у тебя.
Ну и что, что у меня маленькая. Не все же сразу. Пока пусть будет так.
>Ну и цель там очевидна: чтобы как можно больше файлов вписались в один файлрекорд,
>т.е. для ускорения работы с файлами.
У нас с ними цели совпадают. Чудеса да и только :)
>Причём заметь, на этом:
>LONGLONG AllocatedLength;
>......
>экономить не пытаются, хотя и твоим способом сэкономить
>было бы легко (в С есть битовые поля) и можно было бы воспользоваться тем,
>что значения обычно мало отличаются.
Они не пытаются экономить там, где идет описание отдельно взятого объекта.
Лежит он себе в рекорде и никого не трогает. Они только ссылаются на него.
(хотя, если посмотреть способ построения структуры для хранения этих описаний,
то попытки экономии видны сразу, и довольно успешные :)
А как только дело у них доходит до конструкции, содержащей список объектов(ссылок на объекты),
то тут начинается борьба "не на шутку" за каждый бит. :)
← →
Riply © (2007-10-17 17:34) [14]>[12] umbra © (17.10.07 10:15)
>не храните все данные в памяти. Винчестер большой: пользуйтесь MMF.
Хранить можно где угодно.
Но почему из наличия места должно следовать отсутствие
попыток его экономии (если эти попытки не связаны с большими затратами) ?
Страницы: 1 вся ветка
Форум: "Начинающим";
Текущий архив: 2007.11.11;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.048 c