OSDev

С удовольствием. Конкретному техническому вопросу - конкретный технический ответ. Задавайте.

Никак, но речь, в данном случае, о прекомпиляции данных - то есть о внутреннем, а не обменном формате.

Обменные форматы неизбежны, но нет повода делать каждый save в такой формат. Стоимость записи в обменный формат с сериализацией и работой файловой системы навскидку на 3-5 порядков выше, чем прямая запись страницы памяти на диск.

Бред. 3-5 порядков -- это 1000 - 100 000 раз. Учитывая, что скорость ввода-вывода для традиционных дисков в тысячи раз медленнее, чем скорость обработки данными процессором (а SSD чрезвычайно дороги и имеют малую ёмкость, поэтому подходят лишь для определённого круга задач), преобразование данных перед записью или после считывания скажется на времени от момента начала операции и до приведения данных в необходимый формат в очень малой степени. Ну а если использовать асинхронный ввод-вывод (не дожидаться, пока диск соизволит записать или прочитать очередную порцию данных, а, запустив ввод-вывод с одной порцией, продолжать работу над следующими), то время загрузки или сохранения документа вообще практически сведётся к времени ввода-вывода. Наконец, если "обменный формат" подразумевает упаковку данных, в то время как рабочий ("прекомпилированный") имеет распакованный вид, то время сохранения или загрузки такого рабочего представления может оказаться в разы больше, чем упакованного "обменного" формата.

Число раз оценено верно.

pageout требует исполнения нескольких сот строк кода, причём - линейного. пейджфолт, постановка страницы в очередь, запуск io в драйвере, прерывание, снятие семафора. всё. при этом сами ДАННЫЕ совершают ОДНО ПЕРЕМЕЩЕНИЕ. Прямо из памяти в диск - и процессор в этом участия не принимает. и записать можно только модификации.

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

вот она и разница в 3-5 порядков. кстати, сделать это в фоне нельзя - сериализовать стейт приложения нужно обязательно синхронно, с остановом работы приложения. в фоне можно только записать сериализованные данные. запись же стейта приложения в фантоме происходит реально асинхронно.

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

И вообще - смотреть надо, как оно будет - предположения достаточно эфемерны. Мне подсказали интересное исследование - реально собрана статистика по пейджингу юниксов и проведён анализ: что будет, если взять юникс и положить его в среду а-ля Фантом, то есть выделять всем приложениям уникальные адреса и никогда не использовать адреса повторно. При этом адреса сегментов кода используются повторно, а сегменты данных всегда уникальны. Оказывается, что годовая потребность адресного пространства имеет вполне вразумительный порядок - типа терабайта - БЕЗ сборки мусора.

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

Я бы сказал по-другому. На более высоком уровне нужна иерархическая система адрессации типа того, что на дисках файловая система. Порядок прежде всего.

Некое дерево. Тогда и процесс обмена данными с другими ОС будет более понятен.

Находим процесс. Далее его данные - объекты, переменные.

Вот Вы (имею в виду Д.Завалишина) везде говорите, что в Вашей ОС не будет файлов.
В том виде, в котором даётся определение файлу в школьном учебнике информатики, безусловно, наличие файла не обязательно.

Просто надо уточнить понятие файла. В моем разумении это:
некое количество инфомации, доступ к которой осуществляется с помощью одного из методов адрессации.

Привычный вариант - это путь к файлу в традиционнной файловой системе.
Но файлом можно считать и любую переменную, в том числе, в ОП, поскольку к переменной можно обратиться, зная её адрес. Т.е. целая переменная - это тоже файл.

Соответственно, чтобы эффективно обрабатывать данные, обмениваться данными и пр., необходимо прежде всего позаботиться о правильном структурировании данных.

«В одну телегу впрячь не можно Коня и трепетную Лань».
Если не нравятся переусложнённые форматы каких-то файлов, то разработайте свои форматы, которые можно записывать и считывать быстро.
Кстати, в Word-е можно включить "быстрый" режим сохранения - инкрементальное сохранение. При этом в конец файла дописывается только изменённая часть документа.

Госсподи, да ЗАЧЕМ?

- все ходят на костылях, давайте их выкинем
- если вам не нравятся эти костыли, придумайте свои, более удобные

Да не нужны форматы файлов. ПРОСТО НЕ НУЖНЫ. Вместе с файлами.

Какой формат файла у google dox? Нет его. Не формат ЭКСПОРТА, а тот, в который оно само внутри себя сохраняется. Но это ЭКСПОРТ - операция, которая нужна в 1% случаев и которая существует только в силу исторических причин. Завтра не будет и её - будет API, и перекидывание документов в другое место будет происходить без файла.

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

Собственно приложение - это тоже объект.

Фантом, насколько я понял, предлагает образ памяти время от времени складировать кусками безотносительно того, что в них хранится (возможно с некоей оптимизацией - путем записи только изменений), т.е. без какого-либо структурирования данных.

Т.е. по большому счёту Фантом не интересуют ни конкретные приложения, ни их данные, а собственно, все состояние системы целиком как таковое.

Однако у пользователя приоритеты совсем иные - пользователя прежде всего интересуют результата его труда.

В связи с этим интересный вопрос возникает. Восстановление системы при частичной утрате данных на восстановление. По всей видимости, запорченное состояние восстановить не удастся. Придется использовать предыдущее состояние. Хотя, наверное, пользовательские данные при традиционнном подходе можно было бы сохранить.

Именование объектов - привычная операция, и, вероятно, она должна существовать. Люди привыкли к тому, что сущности как-то именованы. В Фантоме предполагается дерево имён объектов - просто потому, что оно очень привычно и крайне легко делается - по сути, оно сводится к одному объкту - Map<String,Object> :)

Впрочем, на мой взгляд, это мало помогает обмену данными.

(И, главное, я давно нахожусь не в состоянии обдумывания, а в состоянии реализации. Трепаться надоело. Делать надо.)

Затем, что объединить постоянность (HDD) и оперативность (RAM) это всё-равно что запрячь в одну телегу Коня и Лань. Идея не до конца обдуманная.