Comments 38
HTML элементы дороже чем массив яваскрипта. JSON дешевле и гибче отдавать, чем HTML.
Дороже по размеру? Несомненно передавать верстку с данными накладно, но это уже другой вопрос… Передавать данные можно напрямую в верстке, можно в JSON вместе с страницей или по AJAX…
HTML != DOM
Теперь я понял откуда у меня не понимание этого камента!
Теперь я понял откуда у меня не понимание этого камента!
UFO just landed and posted this here
Я трактовал камент Zibx так:
HTML елементы с прописаными атрибутами имеют больший объем.
А он имел в виду что оперировать DOM дороже чем массивом.
HTML елементы с прописаными атрибутами имеют больший объем.
А он имел в виду что оперировать DOM дороже чем массивом.
Все недостатки данного подхода описаны в комментариях тут:
habrahabr.ru/blogs/webdev/135339/
habrahabr.ru/blogs/webdev/135339/
Спасибо за наводку! Но всеже я считаю, что поиск по строкам и по элементам реализованый нативно браузером со всевозможными оптимизациями, в теории должен работать быстрее чем чисто javascript решение. Также есть ситуаци в которых сервер не доступен(в плагинах и офлайн версиях).
Выше уже писали, что пихать кучу элементов в dom — дорого. Я добавлю, что оптимизируют в основном реалистичные сценарии использования CSS, поэтому ваша теория без тестов голословна. В ситуациях, когда сервер не доступен поможет LocalStorage, а в будущем обе проблемы решит внутрибраузерная реализации sql (если конечно вот это сдвинется с мертвой точки).
В общем согласен,
Но я верю что данный метод имеет право на жизнь. Например, в приложениях где сравнительно небольшое количество элементов и user experience очень важен.
Но я верю что данный метод имеет право на жизнь. Например, в приложениях где сравнительно небольшое количество элементов и user experience очень важен.
Ну а чтобы не быть голословным, вот вам поиск по тем же данным но с использованием quicksearch.http://jsfiddle.net/cr9Lj/
У меня при сравнении CSS и javascript результаты: <1ms против ~4-8ms соответственно (в браузерах Opera 11.6 и Firefox(8\9)
Вопрос производительности нужно исследовать более детально. Но уже сейчас можно сказать, что данный метод превосходит quicksearch в два раза минимум если не на порядок. А где его применять это уже совсем другая песня. Ведь нашлось применение для quicksearch?!
У меня при сравнении CSS и javascript результаты: <1ms против ~4-8ms соответственно (в браузерах Opera 11.6 и Firefox(8\9)
Вопрос производительности нужно исследовать более детально. Но уже сейчас можно сказать, что данный метод превосходит quicksearch в два раза минимум если не на порядок. А где его применять это уже совсем другая песня. Ведь нашлось применение для quicksearch?!
Не-а, не катит.
Львиная доля времени уходит на скрытие-отображение элементов, и в тесте js-варианта это учитывается, а в тесте css-варианта измеряется только скорость записи нескольких строчек в DOM, время обработки нового селектора не учитывается.
На тесте с 50 000 записей ваш вариант все еще показывает 1мс, но при этом браузер подвисает на секунду-две (на первой букве гораздо сильнее чем на остальных).
JS-вариант справляется субъективно быстрее (процентов на 30) чем css-вариант и честно показывает время выполнения.
Так что производительность нужно тестировать дополнительно, вооружившись профайлером (хотя не знаю, умеют ли они показывать время работы css-парсера)
Львиная доля времени уходит на скрытие-отображение элементов, и в тесте js-варианта это учитывается, а в тесте css-варианта измеряется только скорость записи нескольких строчек в DOM, время обработки нового селектора не учитывается.
На тесте с 50 000 записей ваш вариант все еще показывает 1мс, но при этом браузер подвисает на секунду-две (на первой букве гораздо сильнее чем на остальных).
JS-вариант справляется субъективно быстрее (процентов на 30) чем css-вариант и честно показывает время выполнения.
Так что производительность нужно тестировать дополнительно, вооружившись профайлером (хотя не знаю, умеют ли они показывать время работы css-парсера)
Принимается, судя по всему изменение стилей происходит асинхронно…
Таким образом можно предположить что Chrome это дело выполняет синхронно и цифры соответствующие…
Таким образом можно предположить что Chrome это дело выполняет синхронно и цифры соответствующие…
Обновил пост.
http://jsfiddle.net/USvER/aCwrX/embedded/result/
http://jsfiddle.net/USvER/aCwrX/embedded/result/
Я у себя отыскал способ примерно замерить скорость отображения изменений css.
1 Задаём стиль
2 Записываем время
3 Ставим timeout с нулевой задержкой в котором и считаем затраченное время.
И он вызывается как раз после отработки отображения. Но это на фаере а как на остальных работать будет не знаю.
1 Задаём стиль
2 Записываем время
3 Ставим timeout с нулевой задержкой в котором и считаем затраченное время.
И он вызывается как раз после отработки отображения. Но это на фаере а как на остальных работать будет не знаю.
Огромное спасибо за наводку. Очень похоже на правду!
Я обновил пост и Live demo…
http://jsfiddle.net/USvER/aCwrX/embedded/result/
Я обновил пост и Live demo…
http://jsfiddle.net/USvER/aCwrX/embedded/result/
Внутренний SQL уже реализован в некоторых браузерах.
Чувствительность к регистру лишняя
В хроме 16 нет проблем с производительностью.
1мс.
1мс.
а зачем index?
почему не использовать сам innerHTML?
почему не использовать сам innerHTML?
Сам метод подразумевает использование селектора атрибутов [att*=val]. Который выполняет поиск подстроки в атрибуте. Если бы существовал селектор с поиском подстроки в элементе, например, псевдокласс :contains(), я бы был очень счастлив!
Chrome 16 подтормаживает только при отрисовке спрятанных элементов. Чем больше элементов надо показать, тем больше подтормаживает.
Логику реализовывать на css… ммм, мосье знает толк в извращениях!
Меня вынудили. Если существует другое, красивое и быстрое, решение проблемы прошу, поделитесь со мной!
Не, ну с эстетической точки зрения решение может быть интересным, но я бы на работу таких программистов не брал, без обид — мало что вздумается им на CSS реализовать, а есть такие вещи как отладка, тестирование, стандарты.
Многие вещи уже придуманы — бери и пользуйся только, реализации автокомплита есть чуть ли не во всех JS либах. Что касается скорости — я не считаю что разница 5-50-100мс. стоит того, чтобы забивать гвозди микроскопом.
Многие вещи уже придуманы — бери и пользуйся только, реализации автокомплита есть чуть ли не во всех JS либах. Что касается скорости — я не считаю что разница 5-50-100мс. стоит того, чтобы забивать гвозди микроскопом.
Вот… Для вас и ваших задач 100мс это не проблема… Но ведь это не значит что задач где быстродействие, а следовательно и user experience, играет более важную роль.
И я не вижу проблем с тестированием и отладкой, а стандарты создаем мы сами. И для меня user experience стоит на первом месте.!
И я не вижу проблем с тестированием и отладкой, а стандарты создаем мы сами. И для меня user experience стоит на первом месте.!
В данном конкретном случае, я не считаю это проблемой — во-первых, большинство людей разницы в 50мс и не почуют, а во-вторых — это не самый используемый элемент и не самое «узкое место». Да и сейчас не 90-е, когда каждый байт на счету (я не говорю что оптимизировать не нужно, нужно — но если это не идёт в разрез с логикой приложения).
Про сами создаём — это юношеский максимализм, пройдет. У меня тоже было такое: сначала делаешь как попало, потом «по-правильному», а потом уже видишь что 99% нужных вещей уже реализованы и апробированы другими.
Про сами создаём — это юношеский максимализм, пройдет. У меня тоже было такое: сначала делаешь как попало, потом «по-правильному», а потом уже видишь что 99% нужных вещей уже реализованы и апробированы другими.
Где-то в этой цепочке потерялся тот самый момент когда это «апробированое» и «нужное» собственно создается!
А я и не хочу чтобы мой максимализм куда-то пропадал… Я считаю что он мне еще не раз поможет в создании чего-то бОльшего.
А я и не хочу чтобы мой максимализм куда-то пропадал… Я считаю что он мне еще не раз поможет в создании чего-то бОльшего.
>> Где-то в этой цепочке потерялся тот самый момент когда это «апробированое» и «нужное» собственно создается!
Считаю это одним из последних этапов развития. Сделать что-то нужное без знания что другие сделали в этом направлении — очень сложно.
Считаю это одним из последних этапов развития. Сделать что-то нужное без знания что другие сделали в этом направлении — очень сложно.
Вот именно об этом и пост! Я привел вариант существующей технологии и описал свой путь решения этой проблемы.
Вы привели один из десятков существующей технологии. А Dojo, Ext2JS и пр.? Да и на JQ думаю это не единственное решение.
Такое ощущение, что ваше решение хорошее, потому что ваше )
Лан, прекращаю спорить — не царское это дело.
Резюмируя, могу сказать: я против данного решения, поскольку технологии используются не по назначению. Перекладывать какую-либо логику на CSS, предназначенные для визуального оформления элементов, считаю неправильным.
Такое ощущение, что ваше решение хорошее, потому что ваше )
Лан, прекращаю спорить — не царское это дело.
Резюмируя, могу сказать: я против данного решения, поскольку технологии используются не по назначению. Перекладывать какую-либо логику на CSS, предназначенные для визуального оформления элементов, считаю неправильным.
Я тоже не хочу спорить… Я хочу чтобы мою идею услышали…
А ведь «display:none;» тоже логика на CSS… Но используют её ведь потому что это эффективнее чем полность перестраивать дерево DOM!
Ну это так…
А ведь «display:none;» тоже логика на CSS… Но используют её ведь потому что это эффективнее чем полность перестраивать дерево DOM!
Ну это так…
Блин, вы — провокатор! Ну или я не удержался ) Но с displayем пример некорректный — это тоже визуальное оформление: элемент видимый или невидимый. И дело даже не в удобстве-скорости в этом случае. Скрывать элемент удаляя его из DOM-дерева было бы неправильно, поскольку тогда невозможно было бы обратиться к нему через script, что иногда необходимо.
Ну может немного и провокатор = )
Ну правильно — визульно оформление, а поиск тогда что? Это визуальное скрытие «не нужных» элементов от пользователя. Это так сказать передерг, но если смотреть со стороны пользователя это все визуальное представление.
И какая разница: делаешь ли ты выборку из DOM по средствам javascript, а потом по отдельности применяешь на все элементы стиль или создаешь один стиль который делает выборку элементов из DOM с помощью селекторов. По идее вообще один хрен… Но это так сказать в теории =)
На самом деле это действительно что-то вроде proof-of-concept. Потому как действительно не стандартный use case для CSS.
Все мои каменты мне сейчас кажутся действительно странными.
Было приятно пообщатся.
Спасибо за конструктивную критику! Я сегодня научился чему-то новому. Чего и вам желаю!
Ну правильно — визульно оформление, а поиск тогда что? Это визуальное скрытие «не нужных» элементов от пользователя. Это так сказать передерг, но если смотреть со стороны пользователя это все визуальное представление.
И какая разница: делаешь ли ты выборку из DOM по средствам javascript, а потом по отдельности применяешь на все элементы стиль или создаешь один стиль который делает выборку элементов из DOM с помощью селекторов. По идее вообще один хрен… Но это так сказать в теории =)
На самом деле это действительно что-то вроде proof-of-concept. Потому как действительно не стандартный use case для CSS.
Все мои каменты мне сейчас кажутся действительно странными.
Было приятно пообщатся.
Спасибо за конструктивную критику! Я сегодня научился чему-то новому. Чего и вам желаю!
Поиск — это же целое поля для творчества! Например, вы перебираете все элементы на этапе загрузки, чтобы привести их в нижний регистр. Во время их обхода вы могли бы строить дерево в каком-то виде. Например, посимвольно (каждая буква — узел), или каким-то образом поблочно, или по мере различия слов (если нет коллизий на данном символе, то далее не делить слово на символы). Обход такого дерева был бы гораздо быстрее чем перебор всех значений с использованием indexOf.
Так же очевидно, что помимо самого поиска, узким местом является отрисовка, множественные манипуляции с DOM (типа show/hide для каждого элемента) занимает огромное время. Возможно будет быстрее скрывать или даже удалять сразу все элементы, а потом добавлять сразу большой блок в DOM, который нужно будет показать. Или, если этот блок большой, то его можно делить каким-то образом.
Я конечно понимаю, что в этом комменте не дал ни одного совета, так как их нужно пробовать и измерять производительность, но возможно, дал какие-то наводки.
Так же очевидно, что помимо самого поиска, узким местом является отрисовка, множественные манипуляции с DOM (типа show/hide для каждого элемента) занимает огромное время. Возможно будет быстрее скрывать или даже удалять сразу все элементы, а потом добавлять сразу большой блок в DOM, который нужно будет показать. Или, если этот блок большой, то его можно делить каким-то образом.
Я конечно понимаю, что в этом комменте не дал ни одного совета, так как их нужно пробовать и измерять производительность, но возможно, дал какие-то наводки.
В Вашем каменте в точности описывается проблематика поднятая в моем посте. Именно на этом я и хотел заострить внимание: для таких задач должны быть нативные(native), сильно оптимизированые функции. Псевдокласс :contains() мог стать этой функцией!
Я действительно хотел бы увидеть красивое и быстрое решение этой проблемы!
Все перечисленые Вами методы подразумевают написание кода на интерпретируемом языке, который априори проиграет в производительности написаному на компилируемом.
Я действительно хотел бы увидеть красивое и быстрое решение этой проблемы!
Все перечисленые Вами методы подразумевают написание кода на интерпретируемом языке, который априори проиграет в производительности написаному на компилируемом.
Sign up to leave a comment.
Поиск с использованием CSS3