информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеСетевые кракеры и правда о деле ЛевинаВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
С одной стороны все верно, с другой стороны есть чему... 11.06.05 18:52  Число просмотров: 3100
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
С одной стороны все верно, с другой стороны есть чему возразить.

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

Это лучше, чем все читануть в память и работать только тем, что обменов страниц будет на 1 меньше. Зато получается системонезависимая реализация - не надо вызывать функцию, которой в другой операционке может не быть.

> А вот насчет того что система лучше скэширует - недумаю.

Реализацию кэша в ОС писали далеко не дураки и потратили они на это уйму времени не даром. Это можно принимать только на веру. К тому же не надо тратить время на написание кода, программа будет "легче", не будет лишних ошибок, не к чему дублировать код ради мнимого выигрыша в производительности.

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

Одни люди пишут СУБД, другие пишут прикладные программы. Первым не ведом алгоритмы по которым будут работать программы, написанные вторыми. Причем они могут быть разные с точки обращения к данным. На языках БД не очень то разбежишся с оптимизацией доступа к файлам БД.

> Пример: система со страничной организаций VM, ты обращаешся
> к записи которая могла бы вместится на одной странице, но
> так вышло, что граница страниц перерезает ее пополам и
> когда ты обращаешся к ней, то в памяти держится гараздо
> больше мусора, чем если бы запись была выровнена на границу
> страницы (BerkleyDB следит за этим внимательно).
> Касательно баз данных - тоже самое. Ситуация с паралельными
> апдэйтами тяжело переносится. Например у тебя подсчет
> траффика по хостерам, каждый запрос к вебу добавляет еще
> чиселку к одной сумме по определенному домену (апач к
> примеру, работая несколькими процессами, может привести к
> паралельным апдэйтам. А вот если подставить прослойку между
> базой и событиями, которая будет аккумулировать данные и
> через время сливать в базу, то производительность такой
> системы возрастет заметно.

Это и есть кэш ОС.
<theory> Поиск 








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


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