Стиль/оптимизация JavaScript: String.indexOf () против Regex.test ()
Вам нужно указать запрос на высоту, чтобы он «зарезервировал место» для отображения ComboBox.
Посмотрите этот пример, вы можете изменить значение HeightRequest в соответствии с вашими потребностями.
<combobox:SfComboBox HeightRequest="40" x:Name="comboBox"/>
5 ответов
Я запустил некоторые тесты. Первый метод немного быстрее, но не достаточно, чтобы иметь любое реальное значение даже при интенсивном использовании... кроме тех случаев, когда sCompOp могла потенциально быть очень длинная строка. Поскольку первый метод ищет строку фиксированной длины, ее время выполнения очень стабильно, неважно, сколько времени sCompOp добирается, в то время как второй метод потенциально выполнит итерации через всю длину sCompOp.
Кроме того, второй метод будет потенциально соответствовать недопустимым строкам - "и тому подобное <= и тому подобное", удовлетворяет тест...
Учитывая, что Вы, вероятно, делаете работу парсинга оператора в другом месте, я сомневаюсь, что любой пограничный случай был бы проблемой. Но даже если бы это не имело место, то маленькая модификация к выражению решила бы оба вопроса:
/^(>=|<=|<>)$/
Тестирование кода:
function Time(fn, iter)
{
var start = new Date();
for (var i=0; i<iter; ++i)
fn();
var end = new Date();
console.log(fn.toString().replace(/[\r|\n]/g, ' '), "\n : " + (end-start));
}
function IndexMethod(op)
{
return (",>=,<=,<>,".indexOf("," + op + ",") != -1);
}
function RegexMethod(op)
{
return /(>=|<=|<>)/.test(op);
}
function timeTests()
{
var loopCount = 50000;
Time(function(){IndexMethod(">=");}, loopCount);
Time(function(){IndexMethod("<=");}, loopCount);
Time(function(){IndexMethod("<>");}, loopCount);
Time(function(){IndexMethod("!!");}, loopCount);
Time(function(){IndexMethod("the quick brown foxes jumped over the lazy dogs");}, loopCount);
Time(function(){IndexMethod("<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<");}, loopCount);
Time(function(){RegexMethod(">=");}, loopCount);
Time(function(){RegexMethod("<=");}, loopCount);
Time(function(){RegexMethod("<>");}, loopCount);
Time(function(){RegexMethod("!!");}, loopCount);
Time(function(){RegexMethod("the quick brown foxes jumped over the lazy dogs");}, loopCount);
Time(function(){RegexMethod("<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<");}, loopCount);
}
timeTests();
Протестированный в IE6, FF3, Chrome 0.2.149.30
Это напоминает мне о некоторых ранних основанных на JavaScript getElementsByClassName реализациях.
indexOf был намного быстрее, чем использование регулярного выражения, но код, который использовал indexOf, запущенный с предположения, что разработчик разделит имена классов с пробелами (и не вкладки и переводы строки). Честно говоря, некоторые находящиеся в regexp реализации использовали \b (граница слова), который является несовместимым со спецификацией CSS (потому что CSS позволяет дефисы в именах классов).
Используя indexOf для поддержки getElementsByClassName в IE может действительно иметь значение, потому что нет никаких более быстрых альтернатив, и базовый метод считывания/метод set свойства имени класса удобно заменяет вкладки и переводы строки с пробелами.
Действительно ли это - действительно старая часть кода? Это, возможно, было записано, прежде чем regexes широко использовались в JavaScript. В целом похоже, что кто-то пытался быть слишком умным и "оптимизировал" тот оператор или произошел из среды C и не привык к regexes. Регулярное выражение может быть дорогим для использования, но конкатенация строк может быть также и если бы это не находится в цикле, я пошел бы с тем, какой бы ни каждого легче понять (для меня, regex).
Когда-то давно, возможно, было значимое различие в скорости, но оно больше не имеет место. Я думаю, что это также:
- Унаследованный код от (безбожного) Земля Перед REGEX.
- Записанный кем-то, кто не знает о REGEX или боится его.
Я сомневаюсь, что это - вопрос производительности или оптимизации. Я подозревал бы, что автор того кода был просто не удобен или знаком с регулярными выражениями. Также заметьте, как разделенная от запятой строка не разделяется независимо для усиления свойств объектов - возможно также случай отсутствия знакомства с языком.
Например, другой способ протестировать на оператор в разделенном запятыми списке допустимых операторов состоял бы в том, чтобы разделить разделенный запятыми список допустимых операторов и сделать одноразовую инициализацию объекта с операторами как свойства:
var aOps = ">=,<=,<>".split(",");
var allowableOps = {};
for (var iLoop = 0; iLoop < aOps.length; iLoop++) {
allowableOps[aOps[iLoop]] = true;
} //for
Эта маленькая инициализация наверху была бы, вероятно, смещена способностью сделать быстрые поиски:
if (allowableOps[sCompOp]) { ... }
Конечно, это могло закончить тем, что было медленнее в целом, но это - возможно более чистый подход.