информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsЗа кого нас держат?Все любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[Perl] Уточнаю... 19.05.03 19:34  Число просмотров: 1162
Автор: kea Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Так уточню.
Существует некий скрипт, работающий с (возможно) несколькими таблицами, являющихся по сути файлами, в коих находятся множество идентификаторов, ссылающихся так же иногда на другие таблицы [вообщем принцип работы с этими таблицами чем-то напоминает работу с реляционнными БД, но мне важна работа !именно с файлами].
Этот скрипт будет вылит на не-важно-какой-хостинг и меня заботит его скорость работы при, например, большой загруженности сервера.
В частности, меня интересует: разница в скорости работы скрипта, читающего n-раз с диска таблицы-файлы ссылающиеся на друг друга И скрипта читающего 1(один) файл (все категории, группы и т.п. к которым относятся элементы таблицы естественно находятся в той же таблице).
Чтение файла построчное. Не произвольное.
В файлы иногда может производится запись (своего рода модифицирование данных) другим скриптом.

Просьба ответить незамысловато. Я дилетант в perl-программировании. Просьба обойтись без предвзятостей. Спасибо.
<programming>
[Perl] Какой вариант perl-скрипта будет работать быстрее? 19.05.03 00:55  
Автор: kea Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Возник вопрос о скорости работы скрипта, читаеющего данные из плоской текстовой базы.
Ситуация: есть четыре файла (6К, 4К, 0.4К, 0.5К) читаемые скриптом.
Альтернативная ситуация: есть один файл (10К) читаемый скриптом.
Что быстрее четыре обращения к диску за файлами за !уже подготовленными данными или открывать один файл и только потом обрабатывать данные?
[Perl] Какой вариант perl-скрипта будет работать быстрее? 19.05.03 10:08  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Возник вопрос о скорости работы скрипта, читаеющего данные
> из плоской текстовой базы.
> Ситуация: есть четыре файла (6К, 4К, 0.4К, 0.5К) читаемые
> скриптом.

Размер файлов в килобайтах указан, если я правильно понял.

> Альтернативная ситуация: есть один файл (10К) читаемый
> скриптом.
> Что быстрее четыре обращения к диску за файлами за !уже
> подготовленными данными или открывать один файл и только
> потом обрабатывать данные?

Какие обращения к диску? У Вас операционка какая? Она дисковый кэш поддерживает и он включен? Свободных 10 килобайт в ОЗУ найдется? Какова скорость дисковой системы (Кб/сек.) и время доступа к файлам?

Один файл при всех равных условиях быстрее должен прочитаться, дефрагментированность этого файла может увеличить скорость его прочтения раз так в десять-сто. С дискеты он прочтется за пол-секунды. На IBM PC/XT с дисками типа MFM (100кб/сек) за 0.1 сек (если дисковый кэш выключен). У Вас процессор не 286/16 случайно? Хочется, чтоб запрос к базе быстро обрабатывался - милионные доли секунд хотите поймать?
[Perl] Какой вариант perl-скрипта будет работать быстрее? 19.05.03 03:37  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
> Возник вопрос о скорости работы скрипта, читаеющего данные
> из плоской текстовой базы.
> Ситуация: есть четыре файла (6К, 4К, 0.4К, 0.5К) читаемые
> скриптом.
> Альтернативная ситуация: есть один файл (10К) читаемый
> скриптом.
> Что быстрее четыре обращения к диску за файлами за !уже
> подготовленными данными или открывать один файл и только
> потом обрабатывать данные?

Разумеется, все зависит от сложности этой самой обработки данных. Теоретически при таких размерах работа с одним файлом будет чуть быстрее работы с четырьмя, на практике же разница будет малоразличимой. Оптимальный вариант - прогнать скрипты тысячу-другую раз для оценки.
Уточни 19.05.03 03:37  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Возник вопрос о скорости работы скрипта, читаеющего данные
> из плоской текстовой базы.
> Ситуация: есть четыре файла (6К, 4К, 0.4К, 0.5К) читаемые
> скриптом.
> Альтернативная ситуация: есть один файл (10К) читаемый
> скриптом.
> Что быстрее четыре обращения к диску за файлами за !уже
> подготовленными данными или открывать один файл и только
> потом обрабатывать данные?
Как подготовленными, как хранится, в чем отличие между четырьмя файлами и одним (простая конкатенация или еще что-то).

Общий ответ: храни свою базу хоть в одном файле хоть в нескольких с уже подготовленными данными (мож когда уточнишь можно будет говорить точнее, но пока я не понимаю, зачем при каждом запуске скрипта выполнять подготовку, если ее можно сделать еще до создания самого скрипта).
Тут есть два варианта:
1) Все записи в базе имеют однородную структуру (размер всех записей одинаков), тогда для i-й записи достаточно размер записи умножить на номер записи.

2) База неоднородная (записи в базе могут иметь разный размер). Тогда для каждого ключевого поля (по которому собираешься производить поиск) создай отдельный индексный файл. Это будет типа однородная база, содержащая записи одинаковой длины: i-я запись будет хранить смещение i-й записи в основном файле (для которого выполнено индексирование) в отсортированном по этому ключу порядке. Ну или вырожденный случай: хотя бы просто хранить файл со смещениями всех записей в том порядке, в котором они есть в базе.

ЗЫ: быстрое нахождение i-й записи в базе может понадобиться например для бинарного поиска (с логарифмическим временем от размера базы).

ЗЗЫ: Если логарифмическое время не подходит, можно хранить хеш-таблицу для каждого ключевого поля. Время константное, но и необходимый размер памяти на несколько порядков больше.
[Perl] Уточнаю... 19.05.03 19:34  
Автор: kea Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Так уточню.
Существует некий скрипт, работающий с (возможно) несколькими таблицами, являющихся по сути файлами, в коих находятся множество идентификаторов, ссылающихся так же иногда на другие таблицы [вообщем принцип работы с этими таблицами чем-то напоминает работу с реляционнными БД, но мне важна работа !именно с файлами].
Этот скрипт будет вылит на не-важно-какой-хостинг и меня заботит его скорость работы при, например, большой загруженности сервера.
В частности, меня интересует: разница в скорости работы скрипта, читающего n-раз с диска таблицы-файлы ссылающиеся на друг друга И скрипта читающего 1(один) файл (все категории, группы и т.п. к которым относятся элементы таблицы естественно находятся в той же таблице).
Чтение файла построчное. Не произвольное.
В файлы иногда может производится запись (своего рода модифицирование данных) другим скриптом.

Просьба ответить незамысловато. Я дилетант в perl-программировании. Просьба обойтись без предвзятостей. Спасибо.
[Perl] Уточнаю... 19.05.03 20:55  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
Ничего нельзя сказать заранее. Например, сильно фрагментированный файл будет читаться гораздо дольше разных файлов, но лежащих на диске рядом. И наоборот, если файл попадет в непрерывный участок, он конечно же будет читаться быстрее разбросанных по всему диску файлов. Кроме того играет роль стратегия кеширования. Если действительно важна только скорость, то лучше попробовать оба варианта и посмотреть на скорость. Но реально выигрыша, независомого от ситуации, тут быть не должно. Так что лучше руководствоваться другими критериями при выборе: удобство кодирования, удобство подготовки базы и т.д.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach