Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Не говорю, что это метод лишен недостатков. Просто как... 16.04.04 16:18 Число просмотров: 1386
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 16.04.04 16:20 Количество правок: 1
|
Не говорю, что это метод лишен недостатков. Просто как вариант...
> Сабж
Отсутствие принудительной буферизации на уровне системы может положительно повлиять на производительность ввода/вывода.
> Просто его я знаю лучше всего. Ну квотирование количества
> физической памяти, доступной пользовательскому процессу
> насколько я помню есть и в *NIX-ах
Почти везде, кроме ДОСа.
> Ну да. Только почему бы не кинуть сразу в юзерскую память?
> Кроме того, как я уже сказал, большие файлы даже если их
> считать прямо в память будут мепиться в своп.
Мепиться - не значит сразу своповаться. И очень маленькие туда тоже отмепяться.
> Не помню уж точных критериев винды (а у других я и не знал
> никогда), но насколько я помню все зависит как от
> количества этой самой физической памяти, так и от
> количества процессов. Но лимиты ТОЧНО есть - если интересно
> могу поискать документацию
Главное, чтоб эти лимиты не мешали работать...
> Ну это пока ничего не читается можно сразу же кидаться
> исполнять а пока все равно делать не фиг (позиционирование
> идет или чтение) - можно и пособирать запросы
Я имел в виду, что в процессе чтения первых 4к (семь милисекунд), в первую милисекунду другая пользовательская задача выдаст запрос на чтение другого файла, подумав, может быть, еще две-три милисекунды, Винды все-таки решаться удовлетворить ее запрос. Хотя тормознутость Винды как раз и говорит о том, что после получения запроса на чтение файла, она может еще несколько секунд ждать, собирая другие запросы.
> Ну тут да, какие то незаметные преимущества могут быть, но
> опять таки в крайне редких случаях: если я запускаю две
> задачи, требующие активной работы с большими объемами
> данных на разных концах винчестера, то виноват все таки я,
> а не система или программист, писавший запускаемые
> программы. Ибо даже если программу или систему можно
> заточить под такие вот частные случаи, то все равно толк от
> них будет крайне редко, а на штатное исполнение влиять
> будет
Естественно лучше писать под более типичные случаи, если програмка не одноразовая.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
