Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
С одной стороны все верно, с другой стороны есть чему... 11.06.05 18:52 Число просмотров: 3443
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
С одной стороны все верно, с другой стороны есть чему возразить.
> Можно и просто смаппировать файл в память, насколько я
> помню сейчас и в винде такое есть.
Это лучше, чем все читануть в память и работать только тем, что обменов страниц будет на 1 меньше. Зато получается системонезависимая реализация - не надо вызывать функцию, которой в другой операционке может не быть.
> А вот насчет того что система лучше скэширует - недумаю.
Реализацию кэша в ОС писали далеко не дураки и потратили они на это уйму времени не даром. Это можно принимать только на веру. К тому же не надо тратить время на написание кода, программа будет "легче", не будет лишних ошибок, не к чему дублировать код ради мнимого выигрыша в производительности.
> Тебе лучше знать специфику данных и вид обращения к ним, а
> система будет глупо работать как с огромным массивом, что
> заведомо теряет очень многое, что могло бы с оптимизировать
> кэш.
Одни люди пишут СУБД, другие пишут прикладные программы. Первым не ведом алгоритмы по которым будут работать программы, написанные вторыми. Причем они могут быть разные с точки обращения к данным. На языках БД не очень то разбежишся с оптимизацией доступа к файлам БД.
> Пример: система со страничной организаций VM, ты обращаешся
> к записи которая могла бы вместится на одной странице, но
> так вышло, что граница страниц перерезает ее пополам и
> когда ты обращаешся к ней, то в памяти держится гараздо
> больше мусора, чем если бы запись была выровнена на границу
> страницы (BerkleyDB следит за этим внимательно).
> Касательно баз данных - тоже самое. Ситуация с паралельными
> апдэйтами тяжело переносится. Например у тебя подсчет
> траффика по хостерам, каждый запрос к вебу добавляет еще
> чиселку к одной сумме по определенному домену (апач к
> примеру, работая несколькими процессами, может привести к
> паралельным апдэйтам. А вот если подставить прослойку между
> базой и событиями, которая будет аккумулировать данные и
> через время сливать в базу, то производительность такой
> системы возрастет заметно.
Это и есть кэш ОС.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
