Одна из основных идей использования побитовых операторов в таких языках, как C ++ / java / C #, заключается в том, что они очень быстрые. Но я слышал, что в javascript они очень медленные (по общему признанию, несколько миллисекунд, вероятно, сегодня не имеют большого значения). Почему это так?
(в этом вопросе обсуждается, когда используются побитовые операторы, поэтому я меняю фокус этого вопроса на производительность.)
Когда бы вы хотели их использовать? Вы могли бы использовать их, когда хотите выполнять побитовые операции. Точно так же, как вы использовали бы логические операторы для выполнения логических операций и математические операторы для выполнения математических операций.
Если вы знакомы с побитовыми операторами, их вполне естественно использовать в некоторых приложениях. Их можно использовать для многих целей, кроме переоптимизированного логического массива. Конечно, эти обстоятельства не очень часто возникают при программировании на Javascript, но это не причина, по которой операторы не должны быть доступны.
Это довольно старый вопрос, но на обновленную версию, похоже, никто не ответил.
Падение производительности, которое вы получаете с помощью JavaScript, которого нет в C / C ++, - это приведение из представления с плавающей запятой (как JavaScript преобразовывает все свои числа) в 32-битное целое число для выполнения битовой манипуляции и обратно.
Никто больше не пользуется заклятием?
function hextoRgb(c) {
c = '0x' + c.substring(1);
return [(c >> 16) & 255, (c >> 8) & 255, c & 255];
}
var c1 = hextoRgb('#191970');
alert('rgb(' + c1.join(',') + ')');
return /#([0-9a-f]{2})([0-9a-f]{2})([0-9a-f]{2})/i.exec(c).slice(1).map(function(e) {return parseInt(e, 16);});.
- person Robert; 11.07.2013
Я использую побитовый сдвиг нуля в JS для быстрого целочисленного усечения:
var i=3.141532;
var iTrunc=i>>0; //3
>>> для усечения до 32-битного значения без знака.
- person hippietrail; 17.12.2017
Я нашел полезную информацию @ http://dreaminginjavascript.wordpress.com/2009/02/09/bitwise-byte-foolish/
Судя по всему, в наши дни они выступают очень хорошо. Зачем вам их использовать? По той же причине, что и где-нибудь еще.
Существует эмулятор NES, написанный на JavaScript - кажется, он много использует побитовые операции.
Я думаю, что разработчик должен сделать оператора эффективным или неэффективным. Например, нет ничего, что мешало бы разработчику JavaScript создать виртуальную машину JITting, которая превращает поразрядную операцию в 1 машинную инструкцию. Так что нет ничего изначально медленного в «побитовых операторах в JavaScript».
Я сомневаюсь, что побитовые операции особенно медленны в javascript. Поскольку такие операции могут напрямую отображаться на операции ЦП, которые сами по себе достаточно эффективны, похоже, что у побитовых операций нет какой-либо неотъемлемой характеристики, которая заставила бы их быть непоправимо медленными в javascript.
Редактировать декабрь 2015 г.: я исправлюсь! Падение производительности, которое испытывает Javascript в отношении побитовых операций, происходит из-за необходимости преобразования из числа с плавающей запятой в int и обратно (поскольку все числовые переменные в Javascript хранятся как значения с плавающей запятой). Спасибо Чаду Шуггинсу за указание на это.
Тем не менее, как указано в нескольких ответах, существуют различные приложения javascript, которые полагаются на побитовые операции (например, криптография и графика) и которые не особенно медленные ... (см. Silky и Snarfblam на этой странице). Это говорит о том, что, хотя они и медленнее, чем C / C ++ и другие языки, которые напрямую переводят побитовые операции в отдельные собственные инструкции ЦП, побитовые операции все так же медленны.
Тем не менее, давайте рассмотрим возможность того, что некоторые конкретные причины заставили различных разработчиков хостов javascript реализовывать побитовые операции таким образом, чтобы они были чрезвычайно медленными, и посмотрим, имеет ли это вообще значение ...
Несмотря на то, что javascript использовался для других целей, этот язык чаще всего используется для предоставления услуг пользовательского интерфейса.
Кстати, я вовсе не имею в виду это уничижительно; выполнение этих интеллектуальных функций пользовательского интерфейса и с учетом различных ограничений, налагаемых на язык, а также слабого соблюдения стандартов, требовало - и продолжает требовать - талантливых хакеров javascript.
Дело в том, что в контексте требований к типу пользовательского интерфейса необходимость в количестве побитовых операций, которые могут выявить медлительность javascript в обработке таких операций, в лучшем случае является редкостью. Следовательно, для типичного использования программисты должны использовать побитовые операции там, где и если этот подход кажется хорошо сочетающимся с общей программой / данными, и они должны делать это, не заботясь о проблемах с производительностью. В маловероятном случае производительности. узкое место, возникающее из-за побитового использования, всегда можно реорганизовать, но лучше держаться подальше от ранней оптимизации.
Заметным исключением из вышеизложенного является введение canvas в современных браузерах, мы можем ожидать, что от хостов javascript потребуются более примитивные графические функции, а такие операции могут потребовать в некоторых случаях больших доз побитовые операции (а также здоровые математические функции). Вполне вероятно, что эти службы в конечном итоге будут поддерживаться с помощью библиотек javascript (и даже в конечном итоге будут добавлены к языкам). Для таких библиотек будут использованы общие знания отрасли, чтобы найти наиболее эффективные подходы. Кроме того, и если действительно есть слабость в производительности javascript с побитовыми операциями, мы получим некоторую помощь, поскольку я предсказываю, что реализации javascript на различных хостах (браузерах) будут изменены для улучшения этой конкретной области. . (Это будет следовать типичной схеме развития javascript, которую мы наблюдали на протяжении многих лет.)
Люди делают интересные вещи на JavaScript.
Например, в нем реализовано множество алгоритмов криптографии (по разным причинам); поэтому, конечно, используются побитовые операторы.
Используя JavaScript в его инкарнации Windows Scripting Host JScript, у вас может возникнуть необходимость использовать побитовые операторы для выбора флагов в значениях, возвращаемых из вызовов WMI или Active Directory. Например, значение User Access для записи пользователя в AD содержит несколько флагов, упакованных в одно длинное целое число.
ADS_UF_ACCOUNTDISABLE = 0x00000002;
if (uac & ADS_UF_ACCOUNTDISABLE == ADS_UF_ACCOUNTDISABLE) {
// user account has been disabled
}
Или чья-то произвольная структура таблицы может содержать такое поле, доступное через ADO с JScript.
Или вы можете захотеть преобразовать некоторые извлеченные данные в двоичное представление на любой платформе только потому, что:
BinaryData = "L";
BinaryString = BinToStr(BinaryData, ".", "x");
// BinaryString => '.x..xx..'
Таким образом, есть множество причин, по которым может потребоваться манипуляция с битами в JavaScript. Что касается производительности, единственный способ узнать это - написать и протестировать. Я подозреваю, что в большинстве случаев это было бы вполне приемлемо, не намного хуже, чем любая другая из множества недостатков, содержащихся в этих системах.
Когда скорость имеет первостепенное значение, вы можете использовать их для битовой маскировки: http://snook.ca/archives/javascript/storing_values/
Кроме того, если вам нужно поддерживать Netscape 4, вы должны использовать их для работы с Document.captureEvents (). Не то, чтобы какая-либо респектабельная компания попросила вас писать JS для NS4 ...
Здесь проводится тестирование множества побитовых операций: http://jsperf.com/rounding-numbers-down/3
Однако не стесняйтесь создавать свои собственные тесты производительности на jsPerf!
