Сейчас ты скажешь, что перформанс не нужен...

Во-первых эта штука в общем случае прячется за компилятор и пользователю она никогда не должна быть видна. Во-вторых, для этого у тебя должно быть стабильное выравнивание объектов в памяти. Ты много знаешь случаев, когда это работает?

Ты знаешь, я могу рассуждать про перформанс потому что я в него умею. И я никогда не говорил, что он не нужен. Я говорил, что люди не понимают, что это такое и как его делать. И думают, что если у них есть правильные инструменты, они автоматом его получат.

Mmap? Прячется за компилятор? Можете расширить мысль?

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

MMAP не делает никакой сериализации, он просто отображает память один в один и прочитать его можно в общем случае только той же самой программой. Речь была про сериализацию

То есть, чтобы детишки не порезались, давайте запретим ножи?

Ну огнестрел же запретили, следующие ножи.

До некоторого возраста да (будут у тебя дети, поймешь). Но тут же вопрос не запретить, Проблема с перформансом, и я об этом много раз говорил, что люди ищут волшебную пилюлю, например правильную абстракцию, и при этом не понимают, что могут выиграть 20% на абстракции, и проиграть 200 на приальном кэшировании, для которого абстракция должна быть не такой "бесплатной", но более гибкой.

И тем не менее выравнивание - это боль и это всегда выстрел в ногу. Впрочем, хорошо согласен. Для этого вообще говоря не нужны сырые указатели, достаточно типов и смещений. Я это делаю в Kmath на ByteBuffer-ах

Проблема с твоей проблемой с перформансом в том, что ты не знаешь случаев, когда отсутствие той же арифметики указателей не даёт сделать быстро. Я бы многое отдал за сырой доступ к памяти в тех же корутинах. Имхо, мы теряем 10-20% только из-за этого.

Вообще, я никогда не понимал подход "это опасно, поэтому давайте запретим". Я наивно предполагаю, что мой коллега обучаем и ему после обучения можно доверить опасную штуку.

> Типов и смещений

То есть указателей.

Представь себе знаю, я тебе даже конкретный пример привел. Тут правда вопрос, а нужен ли тебе прям сырой указатель, или тебе достаточно сделать метод типа putDouble(block, offset). Разумеется, компилятор должен где-то это разложить в те самые указатели, так что на каком-то уровне оно будет нужно.

Не сырых же. Я не прибавляю к указателю число.

Представь себе, байт-буффер - это, конечно, похоже, но совсем не то.

С точки зрения API - то. Ты можешь работать с произвольным сдвигом от начальной точки блока и считывать и складывать типизированные объекты. Да, ты будешь платить за проверку выхода за край блока. Но вопрос не будет ли эта плата оправдана

> в общем случае только той же самой программой
Или любой другой программой, язык / библиотеки которой позволяют гибко определить лейаут объекта в памяти. Щас вон в джавку завезут подобное в рамках панамы, и вообще ничего не будет мешать читать отммапленное ранее сями.

Если она видна в профиле - то плата слишком высока. Мы же за последние проценты боремся.

В джавку уже завезли и оно совсем не так работает, там куда ближе к байт-буфферу, чем к сишным сырым указателям

Ну значит эта проверка должна быть отключаема в экстремальных случаях, но не значит, что ее не должно быть по-умолчанию