Комментарии 6
Неочевидно, кому нужен operator fusion. Stream API разрабатывали ребята из JDK и параллельно шли допилы виртуальной машины с тем, чтобы дополнительный какой-то явный fusion был не нужен. Крайне редко вы напоретесь на ситуацию, когда два подряд идущих map или filter будут медленнее, чем один.
Ну и сравнение, понятно, производится по пунктам, интересным авторам сравнения. К примеру, RxJava 1 боксит просто нереально много и тормозит из-за этого. RxJava 2 уже умнее, но всё равно прямой поддержки небоксированных типов нету. Где колонка с примитивной специализацией? Не хотелось ставить крестик в строчке с RxJava? Пользы в плане быстродействия от неё существенно больше, чем от operator fusion.
Где колонка с примитивной специализацией? Не хотелось ставить крестик в строчке с RxJava? Пользы в плане быстродействия от неё существенно больше, чем от operator fusion.
Это спорный момент, часто гоняете примитивы по стримам по сравнению с ссылочными типами? Operator fusion улучшает большУю часть кейсов использования, а примитивная специализация — частные случаи.
Ну и самое важное — добавление примитивной специализации в RxJava это сотни часов работы, контрибьютить туда всегда было сложно, куча вариантов, которые придется поддерживать только усложнят это, учитывая насколько оно все композируемо.
Ну так я говорю не в смысле "бегом побежали добавлять", а в смысле что сравнивать надо беспристрастнее. Если добавление примитивов в RxJava — сотни часов работы, значит, не надо в табличку галочку про примитивы ставлять?
Параллелизм опять же. Позволяет ли RxJava разбивать источник на части и обрабатывать их независимо? Насколько я понимаю, у них только producer-consumer модель. Производительность может быть существенно разной. В общем, картина неполная и выглядит ангажировано.
Если добавление примитивов в RxJava — сотни часов работы, значит, не надо в табличку галочку про примитивы ставлять?
С такой постановкой вопроса я согласен :) Но с "Пользы в плане быстродействия от неё существенно больше, чем от operator fusion." не очень.
Параллелизм опять же. Позволяет ли RxJava разбивать источник на части и обрабатывать их независимо?
Это всегда можно было сделать руками через кастомный оператор или композицию существующих операторов, но было не очень тривиально и композиция могла снизить производительность.
В 2.0.5 добавлен ParallelFlowable, который позволяет делать часть операций (map/filter/etc) параллельно.
В общем, картина неполная и выглядит ангажировано.
Вот тут не согласен, статья одна из самых точных по всем перечисленным технологиям, обычно на подобные тексты без слез не взглянешь.
Сравниваем Java 8, RxJava, Reactor