Иван Соломенников: а чо мне смотреть на jslint, на такие вещи он говорит "ошибка" или "не надо так делать", и все, никакой информации.
По части инкремента Стоян Стефанов, описывая причины по которым стоит избегать ++, пишет "причина заключается в том, что операторы ++ и -- проявляют «излишнюю хитрость»", а в следующем же абзаце показывает примеры высокопроизводительного итерирования массивов как раз с использованием этих унарных операторов. Так что он не очень последовательный товарищ) Ничего не объяснил
И да, говоря "Стоян Стефанов - Шаблоны программирования и проектирования высококачественных приложений" вы имели ввиду книгу "JavaScript. Шаблоны" ?
Наша с вами переписка занимает ~9300 символов без кода и цитат. Добавьте же еще каких-нибудь 100-150, расскажите мне что не так со скобками и почему унарный инкремент это плохо.
"У вас во втором примере по последней ссылке, переменная location объявляется в глобальной области видимости, а она там не нужна до возникновения события." - как и в остальных. Не очень понял, ну и что? Я-то другие вещи тестировал.
"Также по части фигурных скобок, ай-ай-ай, jslint будет очень сильно и долго ругаться." - а что с ними не так? Все как доктор, то бишь Илья Кантор, прописал
"Переменная i++, тоже лучше так не делать, а использовать i += 1" - ну это уже вообще какая-то соционика) Это-то почему не правильно? (upd: и результаты тестов вторят вам, правда разница в производительности маленькая, но все таки. Кааак? Кааак, Карл?)
Иван Соломенников: "Интересное утверждение что методы класса Array будут работать медленнее чем обычные циклы, но спорить не буду так как реализацию их на С++ не смотрел." - ну так они потому и обычные, что больше ничем не заняты, кроме перебора индексов, и потому же они быстрей. Методы класса Array имеют чуть более сложную логику, учитывающую структурные особенности массивов. О том и велась речь с самого начала: создавая в массиве дырки вы обрекаете себя на использование этих самых методов, ибо если вы все же хотите использовать простые циклы, вам придется вводить соответствующие проверки, что значительно уменьшит их преимущество в производительности. К слову, ES5 методы тоже намного (в ~30 раз) быстрее выполн...; таким образом они тоже не очень любят разреженные массивы, независимо от того вызывается колбэк или нет.
Вообще смотря на ваш код, я вижу почему мы с вами не сходимся во мнениях. Вы абсолютно для каждого действия выбираете более лаконичный код, чем более производительный: если нужно вызвать Array.prototype.slice, вы создаете для этого новый массив; для того чтоб выбрать нужные элементы, вы пользуетесь querySelectorAll, вместо того чтоб сначала выбрать контекст, а потом запустить поиск ...
Если переписать ваш пример, прирост производительности будет ~0-20%. А если переделать его, чтобы массив был разреженным, тогда ваш вариант будет работать в ~30% медленнее. В целом, это все конечно мелочи и большого внимания они не заслуживают, особенно при учете что эта ваша функция выполняется onhashchange и onload, и особенно производительной ее можно не делать. Но все же - если мы имеем возможность упростить код, сделав его менее лаконичным, но более производительным, разве это не стоило бы сделать?
В любом случае, я подумал что верстка статичной рамки с хардкодным разрывом ценности не имеет, и решил что легче сделать оверлэп, что к тому же красивее
1. Если простейшие циклы выполняются быстрее методов ES5, то именно первые и являются разумным выбором,
2. Понять не могу, при чем тут это и какое это отношение имеет к делу? Я на это уже отвечал. Я знаю, что колбэк не будет вызываться для этих элементов. В моем тесте так и происходит. Да даже если б вызывался, я бы сильно не расстроился потому что в вашем варианте производительность и так не составляет 10-и процентов той, от которой вы отказываетесь,
3. Раз вы читаете спецификацию, я вас бесконечно уважаю. Вы правы, я сам их не читал, тут ничего не могу сказать. Но jsperf - это реальная информация о производительности. Не вижу ничего постыдного в том, чтобы замерить реальное время выполнения кода, реализовывающего какой-то гипотетический случай, имеющий спорные моменты. Все же гляньте, демонстрация того что производительность ES5 методов в случае с разреженными и полными массивами ничтожна, по сравнению с производительностью простых циклов,
Хорошо, я согласен с тем, что ваш вариант намного проще, и дальнейшие операции с вашим массивом будет намного проще, читабельнее и лаконичней производить именно посредством методов ES5. Но кажется этот вариант абсолютно непроизводительный, разве нет? Просто приведите пример, в котором применение ваших методов было бы оправдано вещами чуть более важными, чем лаконичность кода, особенно в ситуации когда за нее мы пожертвовали производительностью.
Иван Соломенников: Почему это правильно не значит быстро? Если б мы говорили о музыке или о еще каком искусстве, то да. А тут, мне кажется, другое дело. И уж точно не тот правильный вариант, который делает использование простейших циклов до смешного медленным.
Ну так и напишите другой вариант тоже, хотя бы для энциклопедичности.
Не очень понимаю, к чему вы вспоминаете про метод, которым изначально прошлись по элементу, если я говорю о том, что после такого грубого удаления элемента итерироваться движком ваш дырявый массив будет уже как dictionary, таким образом использование базовых циклов будет затруднено лишними проверками и замедлено (в ~50 раз), а использование методов типа forEach будет сильно замедлено (в ~20 раз). Убедитесь сами
Чувак спрашивает, как правильно удалить элемент. Если один способ настолько замедляет дальнейшую работу с массивом, он точно не может считаться верным, ибо простой проход по вашему массиву по длительности переплюнет даже временные затраты на slice()
Под словом "дырявый" я имею ввиду то, что обычно имееют ввиду говоря слово "дырявый" - в нем есть дырки: если обратиться к массиву по индексу удаленного элемента - получишь undefined, что не всегда будет удобно.
Иван Соломенников: wuuut? Парень бы вроде дал вам понять о чем идет речь и почему ему не нравится ваше решение, даже показал, что именно в этом самом итоге ему не нравится. А в итоге получается вполне себе sparse array. И чем же лучше иметь дырявый массив?
