Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 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&#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 так поступают. Экономия идет чуть ли не на биты !
Так что мои выкрутасы это так... детский лепет по сравнению с мировой революцией :)


 
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.045 c
2-1192796073
andreil
2007-10-19 16:14
2007.11.11
Как сделать дерево CheckBox ов?


6-1154718907
Tiberius
2006-08-04 23:15
2007.11.11
Заполнение html-форм


2-1192705820
koss
2007-10-18 15:10
2007.11.11
ICQ и база данных


2-1192861122
apic
2007-10-20 10:18
2007.11.11
win+d


2-1192788766
OlegMa1
2007-10-19 14:12
2007.11.11
Простой TObject





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский