Какой селектор более эффективен
После ответа Tj Kellie в C # 6.0 вы можете легко иметь одну команду для выполнения конкатенации и встраивания различной информации через интерполяцию строк, а также не иметь строк новой строки, несмотря на определение строки на нескольких строках.
Сложный пример, включающий все это, может выглядеть следующим образом:
public int? BestTime { get; set; }
public int? WorstTime { get; set; }
public int? AvgTime { get; set; }
public int TimeoutReachedCount { get; set; }
public int AllRunCount { get; set; }
public string Str => $@"
Ran {AllRunCount} times;
Reached timeout {TimeoutReachedCount} times;
Best time = {(BestTime.HasValue ? BestTime.ToString() : "N/A")};
Worst time = {(WorstTime.HasValue ? WorstTime.ToString() : "N/A")};
Average time = {(AvgTime.HasValue ? AvgTime.ToString() :"N/A")};"
.Replace(Environment.NewLine, "");
Конечно, необходимо добавить дополнительную осторожность, чтобы добавить пробелы в конце строк, чтобы избежать слияния слов ,
2 ответа
$("img[data-src]") - более быстрый селектор, так как ему нужно будет только взглянуть на теги img, где $("[data-src]") будет смотреть на каждый элемент в DOM с этим атрибутом.
В общем, селекторы идут в следующем порядке эффективности (от самой высокой до наименее эффективной):
- ID
- Класс
- Имя тега [ 1123] Дочерние отношения (
- Потомковые отношения (
foo bar) - Атрибут (
foo[bar="baz"]) - Псевдоклассы (
foo:hover, [116 ])
foo > bar) Другое соображение заключается в том, что CSS-селекторы - это, по сути, поиск по дереву, поэтому чем больше вы можете вырезать из дерева, тем лучше. #foo .bar - это отношение потомков, но если включение #foo исключит большую часть вашего HTML из поиска, это сделает этот селектор более эффективным. Точно так же img[data-src] теоретически будет быстрее, чем [data-src], потому что есть более ограниченный набор элементов, атрибут которых необходимо проверить.
(Я не знаю этого наверняка, но ожидаю, что правила CSS не всегда интерпретируются в строгом порядке справа налево. #foo .bar, например, будет более эффективным если интерпретировать слева направо: сначала ищите элемент ID, тогда вам нужно только проверить его дочерние элементы на .bar вместо поиска по всему документу. Я бы предположил, что очевидные оптимизации производительности, подобные этой, уже встроены в большинство или во все браузеры. engine.)
Есть также некоторые случаи, когда вы можете заменить методы javascript для правил css, такие как $('foo:nth-child(1)') vs $('foo').first() - в этом конкретном случае jQuery быстрее , хотя это конечно, не распространяется на все селекторы (поскольку для них нет соответствующих методов).
Если вы сомневаетесь, вы можете сравнить этот тип материала, просто повторно выполнив выделение (в соответствии с вашим настоящим HTML) в цикле:
benchmark = function(selector) {
var t1 = new Date();
for (var i=0; i<100000; i++) {
var x = $(selector);
}
var t2 = new Date();
console.log(selector, t2-t1, "ms")
}
benchmark('[data-src="bar"]')
benchmark('img[data-src="bar"]')<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<div>
<div data-src="bar"></div>
<img data-src="bar">
</div>... результаты которого подводят меня к моей главной точке: преждевременной оптимизации.
В большинстве случаев, с большинством веб-страниц, это мало что меняет в реальном мире. С очень простым HTML выше, селектор почти не имеет значения даже при 100 000 итерациях. На 10 000 итераций я даже не получаю последовательных результатов, из которых быстрее.
Если вы работаете с относительно большими деревьями HTML и сложными селекторами и начинаете видеть реальные проблемы с производительностью, которые, как вы подозреваете, связаны с этими поисками DOM, , тогда это хорошая идея, чтобы начать тестирование такого рода вещей. (Хотя даже тогда, большую часть времени вы увидите больше улучшений от кэширования и повторного использования предыдущих выборов, чем от тонкой настройки самих выборов.)
Используйте здравый смысл, старайтесь, чтобы ваши селекторы были простыми и понятными. укажите, и используйте их, когда это возможно, но, вероятно, не стоит потеть каждую миллисекунду, если вы не видите реальных проблем с производительностью.