Скорость выполнения ссылок по сравнению с указателями
Один из способов сделать это состоит в том, что вам нужно добавить элементы в этом ArrayList<RequestItem> list, сделав их статическими в классе адаптера, а не в списке действий, который вы передаете адаптеру, тогда функция notifyDataSetChanged () будет работать, если вы хотите показать изменения в списке в режиме реального времени
4 ответа
Существуют некоторые преимущества JIT-компиляции, упомянутой в Википедии:
Код JIT обычно предлагает намного лучшую производительность, чем интерпретаторы. Кроме того, это может в некоторых, или много случаев предлагают лучшую производительность, чем статическая компиляция, поскольку много оптимизации только выполнимы во времени выполнения:
- Компиляция может быть оптимизирована к целенаправленному ЦП и модели операционной системы где выполнение приложения. Например, JIT может выбрать инструкции по SSE2 CPU, когда он обнаруживает, что ЦП поддерживает их. Со статическим компилятором нужно записать две версии кода, возможно с помощью встроенного ассемблерного кода.
- Система может собрать статистические данные о том, как программа на самом деле работает в среде, в которой это находится, и это может перестроить и перекомпилировать для оптимальной производительности. Однако некоторые статические компиляторы могут также взять информацию о профиле в качестве входа.
- Система может сделать глобальную оптимизацию кода (например, встраивание библиотечных функций), не теряя преимущества динамического подключения и без издержек, свойственных к статическим компиляторам и компоновщикам. А именно, при выполнении глобальных встроенных замен статический компилятор должен вставить проверки на этапе выполнения и гарантировать, что виртуальный вызов произошел бы, если фактический класс объекта переопределяет встроенный метод.
- Хотя это возможно со статически скомпилированным, собрал "мусор" языки, система байт-кода может более легко перестроить память для лучшего использования кэша.
Я не могу думать о чем-то связанном непосредственно с использованием ссылок вместо указателей.
В C++ существует два преимущества ссылок, связанных с аспектами оптимизации:
Ссылка является постоянной (относится к той же переменной для ее целой жизни),
Из-за этого для компилятора легче вывести, какие имена относятся к тем же основным переменным - таким образом создание возможностей оптимизации. Нет никакой гарантии, что компилятор добьется большего успеха со ссылками, но он мог бы...
Ссылка, как предполагается, относится к чему-то (нет никакой нулевой ссылки),
Ссылка, которая "ни к чему не относится" (эквивалентный Нулевому указателю) может быть создана, но это не столь легко как создание Нулевого указателя. Из-за этого может быть опущена проверка ссылки для ПУСТОГО УКАЗАТЕЛЯ.
Однако ни одно из этих преимуществ не переносит непосредственно на управляемые языки, таким образом, я не вижу уместность этого в контексте Вашей темы обсуждения.
В целом говорите, ссылки позволяют относиться к тому же объекту от различных мест.
'Указатель' является названием механизма для реализации ссылок. C++, Паскаль, C... имеет указатели, C++ предлагает другой механизм (с немного другими вариантами использования) названный 'Ссылкой', но по существу это все реализации общего понятия ссылки.
Таким образом, нет никакой причины, почему ссылки по определению более быстры/медленнее, чем указатели.
Реальная разница находится в использовании JIT или классического 'честного' компилятора: JIT может данные принимать во внимание, что не доступны для честного компилятора. Это не имеет никакого отношения к реализации понятия 'ссылка'.
Другие ответы являются правильными.
Я только добавил бы, что любая оптимизация не сделает крик различия, если это не будет в коде, где счетчик команд на самом деле проводит много времени, как в жестких циклах, которые не содержат вызовы функции (такие как сравнение строк).