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

P>>Элементарно — вот ты написал багу, когда собака попадает в массив котов, что пролетает в выхлоп. Где искать будешь? Полагаю начнешь везде лепить Cat c = array[i] ?
·>Это надо очень постараться написать такую багу. Т.к. в c#/java голые массивы используются только в низкоуровневом коде и компилятор, и ide предупреждения пишут. Т.е. в прикладном коде такого тупо не будет.

ну да, ну да — у тебя очередной способ "писать без багов"

·>В общем, я не понимаю эту проблему в мире статической типизации. Нет такой проблемы в принципе, имхо.

А я вот очень даже понимаю, сами же джависты регулярно упоминают. А вот ты в полном отрицании

P>>Снова магия полезла. Это у тебя в джаве другого варианта нет. А у меня — есть.
·>Ты опять в терминах json думаешь, опустись уровнем ниже. Причём тут java? В cpu тупо нет такой инструкции. Или у тебя квантовый компьютер, алгоритм Гровера используешь?

Я в курсе, как устроена джавовская хештаблица и в чем разница с устройством жээсного объекта.
У тебя, очевидно, нет никакой разницы между первым и вторым.

P>>Я ж говорю — сложность выше, чем сложность всего одата фремворка
·>Я имел в виду, что генерация — часть фреймворка.

Не надо играть в слова — я уже сказал, что такая генерация будет сложнее самого протокола, т.е. метадата, парсинг, сериализация, пайплайн и куча других приседаний.
Говорю "сложнее", потому что я примерно в курсе, сколько это всё стоит в количестве трудозатрат.

P>>Если ты внимательно будешь читать, то узнаешь, что я в самом начале отметил отставание именно в этом тесте. А вот тебе похоже всё не нравится, что не в пользу джавы.
·>Ты сказал, что причина мультипоток, а на самом деле — jit.

Не надо врать — многопоточность это про другой пример, и ты про это в курсе.
Хоть много потоков, хоть нет — что это принципиально меняет? С другими примерами разница куда меньшая. Это тебе они не нравятся, потому что там "регекспы не той системы".

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

P>>>Элементарно — вот ты написал багу, когда собака попадает в массив котов, что пролетает в выхлоп. Где искать будешь? Полагаю начнешь везде лепить Cat c = array[i] ?
P>·>Это надо очень постараться написать такую багу. Т.к. в c#/java голые массивы используются только в низкоуровневом коде и компилятор, и ide предупреждения пишут. Т.е. в прикладном коде такого тупо не будет.
P>ну да, ну да — у тебя очередной способ "писать без багов"
Ты перевирваешь. Я говорю, что во-первых, такую багу допустить сложнее, т.к. это явный code smells и review проблема пройти. А в ts такой код — норма, других вариатнов тупо не было до недавнего времени. Во-вторых, эта бага детектится на раз — гарантированный CCE, в ts же непредсказуемый результат.

P>·>В общем, я не понимаю эту проблему в мире статической типизации. Нет такой проблемы в принципе, имхо.
P>А я вот очень даже понимаю, сами же джависты регулярно упоминают. А вот ты в полном отрицании
Тебя, надеюсь, не затруднит подкинуть пару примеров такого упоминания.

P>>>Снова магия полезла. Это у тебя в джаве другого варианта нет. А у меня — есть.
P>·>Ты опять в терминах json думаешь, опустись уровнем ниже. Причём тут java? В cpu тупо нет такой инструкции. Или у тебя квантовый компьютер, алгоритм Гровера используешь?
P>Я в курсе, как устроена джавовская хештаблица и в чем разница с устройством жээсного объекта.
P>У тебя, очевидно, нет никакой разницы между первым и вторым.
Жэесный объект устроен сложнее и, как правило, тормознее. Мы же рассматриваем случай когда не jit пытается к полям обращаться и инстансы одного hidden-class-а оптимизирует, а конкретно поиск произвольного поля по строке.

P>>>Я ж говорю — сложность выше, чем сложность всего одата фремворка
P>·>Я имел в виду, что генерация — часть фреймворка.
P>Не надо играть в слова — я уже сказал, что такая генерация будет сложнее самого протокола, т.е. метадата, парсинг, сериализация, пайплайн и куча других приседаний.
P>Говорю "сложнее", потому что я примерно в курсе, сколько это всё стоит в количестве трудозатрат.
Ок, whatever, особенности odata меня не интересуют.

P>>>Если ты внимательно будешь читать, то узнаешь, что я в самом начале отметил отставание именно в этом тесте. А вот тебе похоже всё не нравится, что не в пользу джавы.
P>·>Ты сказал, что причина мультипоток, а на самом деле — jit.
P>Не надо врать — многопоточность это про другой пример, и ты про это в курсе.
P>Хоть много потоков, хоть нет — что это принципиально меняет? С другими примерами разница куда меньшая.
Разобрав все бенчи, мы выяснили, что есть только один вид кода, с которым нода не сливает — последовательная обработка байт-буферов. В всё остальное — слив в разы.

P>Это тебе они не нравятся, потому что там "регекспы не той системы".
Потому что нода даже тут слила, и кому?! питону!

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

P>>ну да, ну да — у тебя очередной способ "писать без багов"
·>Ты перевирваешь. Я говорю, что во-первых, такую багу допустить сложнее, т.к. это явный code smells и review проблема пройти. А в ts такой код — норма, других вариатнов тупо не было до недавнего времени. Во-вторых, эта бага детектится на раз — гарантированный CCE, в ts же непредсказуемый результат.

Никакая не норма, это твои страхи.

P>>·>В общем, я не понимаю эту проблему в мире статической типизации. Нет такой проблемы в принципе, имхо.
P>>А я вот очень даже понимаю, сами же джависты регулярно упоминают. А вот ты в полном отрицании
·>Тебя, надеюсь, не затруднит подкинуть пару примеров такого упоминания.

Читай выделенное.

P>>Я в курсе, как устроена джавовская хештаблица и в чем разница с устройством жээсного объекта.
P>>У тебя, очевидно, нет никакой разницы между первым и вторым.
·>Жэесный объект устроен сложнее и, как правило, тормознее.

Наоборот. Сравнивая с обычной хештаблицей — быстрее.

>Мы же рассматриваем случай когда не jit пытается к полям обращаться и инстансы одного hidden-class-а оптимизирует, а конкретно поиск произвольного поля по строке.

Я и говорю, что ты не в курсе, как всё устроено. Профайлер ты не запуска, код не писал, но мнение имеешь.
Нам что, твою веру обсуждать?

P>>Не надо врать — многопоточность это про другой пример, и ты про это в курсе.
P>>Хоть много потоков, хоть нет — что это принципиально меняет? С другими примерами разница куда меньшая.
·>Разобрав все бенчи,

Какое незамысловатое преувеличение. Ты всерьёз в это веришь, что ты все бенчи разобрал? Слишком сильно похоже на враньё.

> мы выяснили, что есть только один вид кода, с которым нода не сливает — последовательная обработка байт-буферов. В всё остальное — слив в разы.

Из бенчмарков ниже ты упомянул только два — pidigits и regex-resuz. Следовательно, можно предположить, что половина бенчмарков тебе не нравится, вот ты их и игнорируешь.

Java быстрее
fannkuch-redux — менее 10%
n-body — менее 25%
pi-digits — около 50%
fasta — 50%
reverse-complement — около 50%

mandelbrot — ноздря в ноздрю

Node быстрее
spectral-norm — менее 10% <- похоже, ошибка на сайте, джава обгоняет на 10%
regex-redux — в три раза

P>>Это тебе они не нравятся, потому что там "регекспы не той системы".
·>Потому что нода даже тут слила, и кому?! питону!

Правильнее сказать, что здесь джава слила не только жээсу, но и питону.

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

P>А как ты думаешь сериализатор работает? Нужно перебрать свойства рефлексией, получить значения той же рефлексией.

Рефлексией значения получает только очень фиговый сериализатор. Обогнать такой действительно совсем несложно. Ты вот попробуй на JS обогнать newtonsoft или STJ. В случае последнего можешь еще, для смеха, расход памяти на больших документах замерить.

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>А как ты думаешь сериализатор работает? Нужно перебрать свойства рефлексией, получить значения той же рефлексией.

НС>Рефлексией значения получает только очень фиговый сериализатор. Обогнать такой действительно совсем несложно. Ты вот попробуй на JS обогнать newtonsoft или STJ. В случае последнего можешь еще, для смеха, расход памяти на больших документах замерить.

А они что, одата поддерживают?

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

P>А они что, одата поддерживают?

Без понятия, я ODATA не использовал и не планирую. Но сериализация через рефлекшен — 100% фейл.
P.S. Глянул бегло современное состояние дел. Для данных текущая дотнетная реализация вообще не не материализует данные в виде классов. Вместо этого данные пишутся напрямую из источника в JSON. Для сериализации и десериализации меты сейчас используется STJ.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Без понятия, я ODATA не использовал и не планирую. Но сериализация через рефлекшен — 100% фейл.
НС>P.S. Глянул бегло современное состояние дел. Для данных текущая дотнетная реализация вообще не не материализует данные в виде классов. Вместо этого данные пишутся напрямую из источника в JSON. Для сериализации и десериализации меты сейчас используется STJ.

Я не про материализацию. После того, как закончит работать бд/сторадж итд, начинает работу сериализатор. Его задача — обработать дерево объектов, выбросить лишнее, подклеить недостающее согласно АСТ запроса, и только потом выдать json. Здесь еще и валидация работает, генерация всяких линков, параметров, генерация метаданных и тд.
То есть, на самом деле тут целый рендерер, а не только object->json. Генерация json это малая часть всего, что необходимо, ориентировочно 20-25%.

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

P>То есть, на самом деле тут целый рендерер, а не только object->json.

Да пофик. Все равно чтение/запись данных рефлекшеном это, с точки зрения перфоманса, epic fail.

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>То есть, на самом деле тут целый рендерер, а не только object->json.

НС>Да пофик. Все равно чтение/запись данных рефлекшеном это, с точки зрения перфоманса, epic fail.

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

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

P>>>·>В общем, я не понимаю эту проблему в мире статической типизации. Нет такой проблемы в принципе, имхо.
P>>>А я вот очень даже понимаю, сами же джависты регулярно упоминают. А вот ты в полном отрицании
P>·>Тебя, надеюсь, не затруднит подкинуть пару примеров такого упоминания.
P>Читай выделенное.
Т.е. проблемы нет? Что джависты регулярно упоминают-то? Ссылку на упоминание, плз.

P>>>Я в курсе, как устроена джавовская хештаблица и в чем разница с устройством жээсного объекта.
P>>>У тебя, очевидно, нет никакой разницы между первым и вторым.
P>·>Жэесный объект устроен сложнее и, как правило, тормознее.
P>Наоборот. Сравнивая с обычной хештаблицей — быстрее.
За счёт чего?

>>Мы же рассматриваем случай когда не jit пытается к полям обращаться и инстансы одного hidden-class-а оптимизирует, а конкретно поиск произвольного поля по строке.
P>Я и говорю, что ты не в курсе, как всё устроено. Профайлер ты не запуска, код не писал, но мнение имеешь.
P>Нам что, твою веру обсуждать?
Если есть что рассказать, рассказывай.

P>>>Не надо врать — многопоточность это про другой пример, и ты про это в курсе.
P>>>Хоть много потоков, хоть нет — что это принципиально меняет? С другими примерами разница куда меньшая.
P>·>Разобрав все бенчи,
P>Какое незамысловатое преувеличение. Ты всерьёз в это веришь, что ты все бенчи разобрал? Слишком сильно похоже на враньё.
Да.

>> мы выяснили, что есть только один вид кода, с которым нода не сливает — последовательная обработка байт-буферов. В всё остальное — слив в разы.
P>Из бенчмарков ниже ты упомянул только два — pidigits и regex-resuz. Следовательно, можно предположить, что половина бенчмарков тебе не нравится, вот ты их и игнорируешь.
Другие из той же группы. Так и быть, распишу:

P>Java быстрее
P>fannkuch-redux — менее 10%
P>n-body — менее 25%
циклы по байт-буферу (и жрёт памяти двухкратно).

P>pi-digits — около 50%
нативная libmpz.

P>fasta — 50%
Java #4 36,800 3.41
Node #5 101,844 6.38
Что за 50%? Нода в ~2 раза медленнее и в ~3 раза прожорливее.

P>reverse-complement — около 50%
Ок, но в 3 раза прожорливее и в основном байтбуферы.

P>mandelbrot — ноздря в ноздрю
Циклы по байтбуферу.

P>Node быстрее
P>spectral-norm — менее 10% <- похоже, ошибка на сайте, джава обгоняет на 10%
Циклы по байтбуферу.

P>regex-redux — в три раза
Нативная либа.

P>>>Это тебе они не нравятся, потому что там "регекспы не той системы".
P>·>Потому что нода даже тут слила, и кому?! питону!
P>Правильнее сказать, что здесь джава слила не только жээсу, но и питону.
Ты серьёзно?!

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

P>>>>Я в курсе, как устроена джавовская хештаблица и в чем разница с устройством жээсного объекта.
P>>>>У тебя, очевидно, нет никакой разницы между первым и вторым.
P>>·>Жэесный объект устроен сложнее и, как правило, тормознее.
P>>Наоборот. Сравнивая с обычной хештаблицей — быстрее.
·>За счёт чего?

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

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

·>циклы по байт-буферу (и жрёт памяти двухкратно).
·>нативная libmpz.
·>Что за 50%? Нода в ~2 раза медленнее и в ~3 раза прожорливее.
·>Ок, но в 3 раза прожорливее и в основном байтбуферы.
·>Циклы по байтбуферу.
·>Циклы по байтбуферу.
·>Нативная либа.

Вобщем, ничтожные аргументы.

P>>>>Это тебе они не нравятся, потому что там "регекспы не той системы".
P>>·>Потому что нода даже тут слила, и кому?! питону!
P>>Правильнее сказать, что здесь джава слила не только жээсу, но и питону.
·>Ты серьёзно?!

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