Ссылочное различие в производительности равенства? ((объект) obj1 == (объект) obj2) по сравнению с объектом. ReferenceEquals (obj1, obj2)
Вы можете объединить значения индекса и заменить числа определенным шаблоном.
var substr = [1, 2, 3, 4, 5, 6];
var str = substr.join('').replace(/[0-9]/g, (n) => `url${n}=&`).slice(0, -1);
console.log(str);2 ответа
Существуют ли дополнительные издержки при использовании метода object.ReferenceEquals
Нет. Метод напрямую содержит минимальное описание IL для проверки равенства ссылок (для записи: он эквивалентен оператору Is VB) и часто будет вставлен JIT (особенно при нацеливании на x64), поэтому есть нет накладных расходов.
О читабельности: лично я считаю, что object.ReferenceEquals потенциально более читабелен (даже в отрицательной форме), поскольку он явно выражает свою семантику. Приведение к объекту может вводить в заблуждение некоторых программистов.
Я только что нашел статью , обсуждающую это. Предпочитает (объект) x == y , потому что занимаемая площадь меньше. Утверждается, что это может облегчить встраивание метода X с использованием этого сравнения. Однако (без какого-либо подробного знания JIT, но логически и интуитивно) я считаю, что это неправильно: если JIT ведет себя как оптимизирующий компилятор C ++, он рассмотрит метод после , встраивающий вызов в ReferenceEquals , поэтому (для метода встраивания X ) объем памяти будет одинаковым в любом случае.
То есть: выбор одного пути из другого не окажет никакого влияния что бы ни касалось JIT и, следовательно, производительности.
Издержки Object.ReferenceEquals связаны только с загрузкой аргументов, которые в большинстве сценариев удаляются JIT. После этого и Object.ReferenceEquals, и оператор == сводятся к одному оператору IL ceq. В худшем случае, разница будет незначительной.
Что еще более важно, Object.ReferenceEquals гораздо лучше раскрывает намерения, чем (object) o1 == (object) o2. Это четко указано в коде «Я проверяю референтное равенство / идентичность» вместо того, чтобы скрывать намерение под кучей забросов.