Nano Hash - криптовалюты, майнинг, программирование

Производительность thenComparing vs thenComparingInt — что использовать?

У меня вопрос: если я сравниваю целые числа, есть ли разница в производительности при вызове thenComparingInt(My::intMethod) и thenComparing(My::intMethod), другими словами, если я сравниваю разные типы, как ссылочные, так и примитивный, т.е. Строка, целое число и т. д. Часть меня просто хочет сказать сравнение (). затем сравнение (). затем сравнение () и т. д., но должен ли я делать сравнение. ?

Я предполагаю, что сравнение () и затем сравнение () используют метод compareTo для сравнения любого заданного типа за кулисами или, возможно, для целых чисел, Integer.compare? Я также предполагаю, что ответ на мой первоначальный вопрос может включать в себя производительность, заключающуюся в том, что thenComparingInt будет знать, что передается int, тогда как thenComparing должен автоматически упаковать int в Integer, а затем, возможно, привести к Object?

Кроме того, еще один вопрос, пока я думаю об этом - есть ли способ связывания ссылок на методы, например. Song::getArtist::length, где getArtist возвращает строку? Причина в том, что я хотел сделать что-то вроде этого:

songlist.sort(
            Comparator.comparing((Song s) -> s.getArtist().length()));


    songlist.sort(
            Comparator.comparing(Song::getArtist, 
                    Comparator.comparingInt(String::length)));


    songlist.sort(
            Comparator.comparing(Song::getArtist, String::length));

Из трех примеров два верхних компилируются, но нижний, кажется, выдает ошибку компиляции в Eclipse, я бы подумал, что второй аргумент String::length действителен? Но, может быть, нет, поскольку он ожидает, что компаратор не является функцией?


Ответы:


1

Вопрос 1

Я бы подумал, что thenComparingInt(My::intMethod) может быть лучше, поскольку он должен избегать бокса, но вам нужно попробовать обе версии, чтобы увидеть, действительно ли это имеет значение.

вопрос 2

songlist.sort(
        Comparator.comparing(Song::getArtist, String::length));

Недопустимо, потому что 2-й параметр должен быть Comparator, а не методом, который возвращает int.

27.06.2014
  • Я предполагаю, что с примитивной специализацией будет достигнута очень небольшая производительность. При анализе побега не возникнет особых проблем с обнаружением того, что автоупаковка int ограничена областью действия метода сравнения, а затем можно встроить метод Integer.compareTo, чтобы получить почти тот же результат, что и без автоупаковки. Таким образом, бенчмаркинг является обязательным, чтобы найти реальную разницу. 27.06.2014
  • @MarkoTopolnik Если бы только это было так. Было проведено множество реальных измерений, прежде чем мы решили включить примитивные потоковые специализации. При этом производительность редко является самым важным требованием; если у вас есть шесть элементов в вашей коллекции, сортировка, вероятно, будет достаточно быстрой, независимо от того, сколько вы боксируете, а достаточно быстро — это достаточно быстро. 28.06.2014
  • @BrianGoetz Действительно, я сравнил Arrays.sort(integerArray, comparing(Integer::intValue)); с Arrays.sort(integerArray, comparingInt(Integer::intValue));, и соотношение производительности было 3,5: 1 в пользу примитивной специализации при использовании целых чисел за пределами диапазона кэша целых чисел; в пределах диапазона кеша (0..127) производительность боксового варианта была лучше (2 к 1). Это указывает на то, что Escape Analysis не позволяет выделять стек, основываясь на моем предыдущем наблюдении, что целые числа EA работают лучше, чем при поиске из кеша. 28.06.2014
  • @BrianGoetz ... следуя вышеизложенному, я также проверил Arrays.sort(integerArray, comparing(i->new Integer(i.intValue()))); --- и, о чудо, в этом случае соотношение было всего 1,5 к 1. Я упустил из виду, что Integer.valueOf (другими словами, автоупакованный код) не может быть EA'd из-за пути кода, включающего поиск в кеше. Так что мой прогноз все-таки верен: при включенном советнике разница становится совсем небольшой. 28.06.2014
  • (перечитывая вышесказанное, я вижу место для путаницы, когда я говорю, что производительность коробочного варианта была лучше; я имел в виду, что производительность коробочного варианта улучшена --- с 3,5: 1 в пользу примитивного вариант до 2:1) 28.06.2014
  • К настоящему моменту я не совсем уверен, в чем состоит ваш аргумент , но кажется, что примитивные потоки не были необходимы, потому что EA избавляет от проблем с боксом, что совершенно неверно. Советник работает хорошо в одних ситуациях и ужасно в других; в зависимости от местоположения вашей деятельности эти проблемы могут доминировать в затратах на упаковку/распаковку, из-за чего они выглядят дешевле, чем они есть на самом деле. Кроме того, вы сравниваете чистую последовательную производительность или параллельное ускорение? Опять же, в зависимости от того, что вы измеряете, вы можете увидеть очень разные результаты. Итог: хотелось бы, чтобы EA работал так надежно, как вы думаете. 28.06.2014
  • @MarkoTopolnik Я согласен со всем, что говорит Брайан Гетц, учитывая, что он один из авторов Java 8. 28.06.2014
  • @BrianGoetz Я знаю, что вы немного обидчивы в этом вопросе и, вероятно, уже получили много критики, но я просто развлекался своим энтузиазмом по поводу производительности JVM :) Я интуитивно это понял, в этом частном случае, советник должен работать. И я был не прав, но не совсем так: это сработало, но только когда я использовал явный конструктор Integer --- который, кстати, можно интерпретировать как подсказку о том, как сделать важное улучшение производительности бокса. Следует пытаться использовать EA без учета техники автоупаковки и использовать конструктор вместо фабрики, если EA преуспеет. 28.06.2014
  • @dkatzel Брайан больше, чем просто один из авторов — он занимает должность главного архитектора языка Java :) 28.06.2014
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

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

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

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

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..