Здравствуйте, ·, Вы писали:

·>А моя основная претензия, что внутре там всё тот же js, т.е. все эти проверки типов существуют только в момент компиляции. Т.е. ошибки с типами (особенно при наличии конверсий или|и js-кода) не локализуются, а могут валиться в любом месте или давать практически непредсказуемое поведение. Т.е. в каком-то смысле аналог порчи памяти.

Ты пересказываешь байки десятилетней давности. Что такое было нормой — я такого не встречал ни на одном проекте.

P>>То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд.
·>Dog это (is-a) и object, и базовый класс, т.е. это не будет ошибкой в системе типов. Т.е. если будет другое присвоение, то всё будет прекрасно работать, это не ошибка.
·>Иными словами, у тебя или корректное поведение, или class cast exception в конкретном месте. Очень облегчает поиск багов.

Смешная вещь. Ты стесняешься сказать, что тебе придется написать ручной валидатор всех таких коллекций, например, потому, что в БЛ используется обобщенный код. И если тебя зареквестали список котов, пользователь не жаждет увидеть в ём собаку.

P>>Дешевый относительно чего? Обращение к хештаблице это несколько вызовов, небольшая кучка приседаний. Как то странно — пяток-десяток примитивных операций оказываются вдруг всего на 10% больше, чем одна такая операция.
P>>Поделись, что это за чудо такое?
·>Вызовы инлайнятся же. Дешевый относительно полезной работы, совершаемой программой. Сотня-другая маш-операций никакого измеримого влияния не оказывают на типичный http-запрос.

Относительно абстрактного хттп запроса 10% это чудовищное количество времени. А для сериализатора будет не 10% а разы. То есть, пейлоад ты будешь отдавать не милисекунды...десятки а сотни. Что собственно и происходит. И это только сериализация.

·>Я знаю, эту мысль и пытаюсь донести. Там и gc, и с jit ситуация получше. Как минимум, банально больше человеколет вложено. Ну и сама платформа, т.к. не динамика, проще/лучше оптимизируется. Собственно поэтому нода всегда будет в догоняющих по перформансу.

Судя по бенчмаркам, джава недалеко ушла.

P>> Доступ к такому кешу будет бесплатный, да?
·>Не дороже, чем доступ к полю в js.

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

P>>·>А lookup как работает по-твоему? Там возможно есть какие-то оптимизации, но в общем случае та же hashtable.
P>>В том то и дело, что не та же хештаблица. В общем случае именно хештаблицы не будет, т.к. слишком дорого.
·>А какие ещё варианты по строке извлекать значение? Такую маш-инструкцию в процы ещё не завезли.

Все очень просто — хештаблица общего назначения крайне медленная. Если мы знаем, что именно, как и где будем хранить, то можно и нужно сделать частный случай. Что и сделано для жээса.
Можно ноду вытолкнуть в такой же режим, что бы ключи-значения хранились как в хештаблице общего назначения, и тогда получим замедление примерно в 5-10 раз.

P>>Теоретически. Одна проблема — написать такой кодогенератор задача непосильная для большинства команд, при этом он требует постоянного мейнтенанса.
·>Это не надо писать большинству команд. Такое надо писать только автору odata библиотеки.

Такой кодогенератор в целом сложнее всего одата процессинга включая серилизацию, парсинг, пайплайн, метадату итд.
ю.
P>>Ты же сам предлагаешь тот самый кактус. Никакой адекватно альтернативы у тебя нет.
·>Ладно, сдаюсь. Я не теме, что за задачу решает odata и какие есть альтернативы.

graphql есть альтернатива. Намного медленнее, и менее функциональный. Зато больше обложен тулами, библиотеками итд.

·>Но что он там предлагает, это нарушает

Ты снова читаешь не то, не там, не так. Его главный поинт — что код этот есть синтетический микробенчмарк, и он подробно объясняет, что не так с кодом.

Здравствуйте, ·, Вы писали:

·>А моя основная претензия, что внутре там всё тот же js, т.е. все эти проверки типов существуют только в момент компиляции. Т.е. ошибки с типами (особенно при наличии конверсий или|и js-кода) не локализуются, а могут валиться в любом месте или давать практически непредсказуемое поведение. Т.е. в каком-то смысле аналог порчи памяти.

Ты пересказываешь байки десятилетней давности. Что такое было нормой — я такого не встречал ни на одном проекте.

P>>То есть, условно, т.к. далеко не факт, что будет именно такое присвоение. А может будет просто object или базовый класс итд.
·>Dog это (is-a) и object, и базовый класс, т.е. это не будет ошибкой в системе типов. Т.е. если будет другое присвоение, то всё будет прекрасно работать, это не ошибка.
·>Иными словами, у тебя или корректное поведение, или class cast exception в конкретном месте. Очень облегчает поиск багов.

Смешная вещь. Ты стесняешься сказать, что тебе придется написать ручной валидатор всех таких коллекций, например, потому, что в БЛ используется обобщенный код. И если тебя зареквестали список котов, пользователь не жаждет увидеть в ём собаку.

P>>Дешевый относительно чего? Обращение к хештаблице это несколько вызовов, небольшая кучка приседаний. Как то странно — пяток-десяток примитивных операций оказываются вдруг всего на 10% больше, чем одна такая операция.
P>>Поделись, что это за чудо такое?
·>Вызовы инлайнятся же. Дешевый относительно полезной работы, совершаемой программой. Сотня-другая маш-операций никакого измеримого влияния не оказывают на типичный http-запрос.

Относительно абстрактного хттп запроса 10% это чудовищное количество времени. А для сериализатора будет не 10% а разы. То есть, пейлоад ты будешь отдавать не милисекунды...десятки а сотни. Что собственно и происходит. И это только сериализация.

·>Я знаю, эту мысль и пытаюсь донести. Там и gc, и с jit ситуация получше. Как минимум, банально больше человеколет вложено. Ну и сама платформа, т.к. не динамика, проще/лучше оптимизируется. Собственно поэтому нода всегда будет в догоняющих по перформансу.

Судя по бенчмаркам, джава недалеко ушла.

P>> Доступ к такому кешу будет бесплатный, да?
·>Не дороже, чем доступ к полю в js.

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

P>>·>А lookup как работает по-твоему? Там возможно есть какие-то оптимизации, но в общем случае та же hashtable.
P>>В том то и дело, что не та же хештаблица. В общем случае именно хештаблицы не будет, т.к. слишком дорого.
·>А какие ещё варианты по строке извлекать значение? Такую маш-инструкцию в процы ещё не завезли.

Все очень просто — хештаблица общего назначения крайне медленная. Если мы знаем, что именно, как и где будем хранить, то можно и нужно сделать частный случай. Что и сделано для жээса.
Можно ноду вытолкнуть в такой же режим, что бы ключи-значения хранились как в хештаблице общего назначения, и тогда получим замедление примерно в 5-10 раз.

P>>Теоретически. Одна проблема — написать такой кодогенератор задача непосильная для большинства команд, при этом он требует постоянного мейнтенанса.
·>Это не надо писать большинству команд. Такое надо писать только автору odata библиотеки.

Такой кодогенератор в целом сложнее всего одата процессинга включая серилизацию, парсинг, пайплайн, метадату итд.
ю.
P>>Ты же сам предлагаешь тот самый кактус. Никакой адекватно альтернативы у тебя нет.
·>Ладно, сдаюсь. Я не теме, что за задачу решает odata и какие есть альтернативы.

graphql есть альтернатива. Намного медленнее, и менее функциональный. Зато больше обложен тулами, библиотеками итд.

·>Но что он там предлагает, это нарушает

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