Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

дефрагментация файла

Страницы: 1 2 3 >
mem © (2010-11-24 16:13:00)
Всем привет!
Собственно сабж - как мне записать файл данных одним последовательным куском(или потом дефрагментировать)? Вероятно, без Win API не обойтись, только я не знаю, что гуглить, подскажите, плиз. Или какой-нибудь более простой способ, подходящий для задачи - дефрагментация указанного файла. Размер в пределах 1 Гб. Предполагаем, что на диске есть свободный кусок нужного размера. (потом можно откинуть предположение или сразу - если не очень усложнит решение)

mem (2010-11-25 13:59:00) [1]

> в mssql страничная организация данных, и фрагментированность
> индексов, в отличие от дисковой, говорит, что данные не
> просто не по порядку, а "размазаны" по куче страниц, частично
> пустых. т.е. там не просто "не порядок" там придется считать
> все страницы (размер*количество=?) для работы с ним. т.е.
> выбор между прочитать например 1 полную страницу, или 200
> чуть заполненных. разница однако.

ясно

> сделал бы лучше выводы. чем велосипеды изобретать, и ехидствовать
> когда на это указывают.

одно другому...

sniknik (2010-11-25 13:50:00) [2]
> Хорошо, тогда почему фрагментированность индексов в том же MS SQL Server очень заметно влияет?
потому что общее тут только слово "фрагментированность" использующееся для разных понятий.

в mssql страничная организация данных, и фрагментированность индексов, в отличие от дисковой, говорит, что данные не просто не по порядку, а "размазаны" по куче страниц, частично пустых. т.е. там не просто "не порядок" там придется считать все страницы (размер*количество=?) для работы с ним. т.е. выбор между прочитать например 1 полную страницу, или 200 чуть заполненных. разница однако.

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

mem (2010-11-25 13:18:00) [3]

> Игорь Шевченко © (25.11.10 13:15) [39]

наконец-то, дождались.

Игорь Шевченко (2010-11-25 13:15:00) [4]
Дети Ивана Кулибина

mem (2010-11-25 12:52:00) [5]
впрочем, хрен с ней, с дефрагментацией - индексы загоню в память, конечно

mem (2010-11-25 12:52:00) [6]
Всем спасибо, значит дефрагментация файла мало влияет на производительность. Хорошо, тогда почему фрагментированность индексов в том же MS SQL Server очень заметно влияет? Ведь это одно и то же по сути - фрагментирован файл->фрагментирован индекс.

> DiamondShark © (25.11.10 00:58) [29]

>
> З.Ы.
> Всё-таки, критерий желания странного практически безошибочный
> ;)

не торопись с выводами.

> Но, скорее всего, алгоритм индексирования фиговый, если
> он НАСТОЛЬКО сильно деградирует в условиях, отличных от
> сферического вакуума.

см. выше про индексы.

Может надо было сразу сказать? Программка будет получать много поисковых запросов последовательно - десятки, сотни тысяч, поэтому экономия каждой капли времени будет заметна в конечном итоге. Если б нужно было обработать один запрос, я б не парился.

Дмитрий Белькевич (2010-11-25 11:23:00) [7]
Господа. Поставлена конкретная задача. Зачем теоретизировать об общих случаях? 1 гиг вполне реально держать в памяти современной средней машины с, думаю, 2-мя гигами оперативки. Ну нужен человеку быстрый доступ к данным настолько, что он уже в оптимизацию на уровне жёсткого полез. Зачем это ему? Пусть в памяти всё делает.

Дмитрий Белькевич (2010-11-25 11:18:00) [8]

> Признайся: TPAW -- твой клон.

Это кто? :) Не знаю такого...

DiamondShark (2010-11-25 11:10:00) [9]

> Дмитрий Белькевич (25.11.10 11:07) [33]
> А зачем непрерывный кусок?

Признайся: TPAW -- твой клон.

Дмитрий Белькевич (2010-11-25 11:07:00) [10]
А зачем непрерывный кусок? Seek в памяти, в отличие от веников, из-за чего и происходят основные тормоза при фрагментации, равен нулю.

> Забудьте миф о "дешёвой оперативной памяти". В конкурентной
> многозадачной среде виртуальная память -- это ДИСКОВАЯ память
> с кэшированием в ОЗУ.

Своп можно выключить, что я у себя давно и сделал. Производительность сильно возросла. Иногда, правда, бывает, не хватает памяти. Но это, обычно, не чаще раза в 2-3 месяца. Перезагрузка помогает, не всё же машину в хибернейте держать.

Германн (2010-11-25 02:42:00) [11]

> Дмитрий Белькевич (25.11.10 01:13) [30]
>
> >Размер в пределах 1 Гб.
>
> В памяти всё держать - не?

Можно подумать, что память в отличие от диска не фрагментирована.

P.S. Тут вспомнилось какое-то обсуждение о скорости доступа к секторам диска. Где убедительно было доказано, что максимальную скорость доступа к данным на диске можно получить "особым" расположением данных по секторам диска.

DiamondShark (2010-11-25 01:24:00) [12]

> В памяти всё держать - не?

1. В памяти, скорее всего, не окажется непрерывного региона в 1 ГБ.
(Если, конечно, не 64-битная ОС)
Придётся городить огород с "окнами" доступа.

2. Страницы из региона размеров в 1 ГБ с большой вероятностью будут откачиваться.
Забудьте миф о "дешёвой оперативной памяти". В конкурентной многозадачной среде виртуальная память -- это ДИСКОВАЯ память с кэшированием в ОЗУ.

> и на фрагментацию можно забить.

Но придётся вспомнить о фрагментации свап-файла ;)

Разницы между "в памяти всё держать" и "на диске всё держать" почти нет.

Дмитрий Белькевич (2010-11-25 01:13:00) [13]
>Размер в пределах 1 Гб.

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

DiamondShark (2010-11-25 00:58:00) [14]

> очень, очень смущает, но как избавиться?))

1. Написать драйвер файловой системы
2. Использовать выделенный раздел
3. Поставить дисковый контроллер с 16 ГБ кэша.
...
4. PROFIT!!!

Но, скорее всего, алгоритм индексирования фиговый, если он НАСТОЛЬКО сильно деградирует в условиях, отличных от сферического вакуума.

З.Ы.
Всё-таки, критерий желания странного практически безошибочный ;)

mem (2010-11-24 23:56:00) [15]

> Anatoly Podgoretsky © (24.11.10 23:39) [27]
>
> > mem (24.11.2010 23:29:26) [26]
>
> Это все комплексы.

верю

Anatoly Podgoretsky (2010-11-24 23:39:00) [16]
> mem (24.11.2010 23:29:26) [26]

Это все комплексы.

mem (2010-11-24 23:29:00) [17]

> Rouse_ © (24.11.10 23:07) [24]

спасибо

Плохиш (2010-11-24 23:12:00) [18]
Прикольная ветка...

Rouse_ (2010-11-24 23:07:00) [19]
Выигрыш будет в районе 200-300мс на файле размером в 3 гигобайта (есесн если не читать его махонькими кусочками). Я решал подобную задачу и в итоге плюнул на фрагментацию - ибо сэкономленное на чтение время не стоит времени затраченное на реализацию записи без фрагментации.

sniknik (2010-11-24 23:02:00) [20]
> серьезно? Про фрагментированность индексов мы не слышали...
очень...
http://img708.imageshack.us/i/msfrag.png/
и никто не "парится"

> в первую очередь, пиарщикам
не приписывайте другим свои недостатки...

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »