Показать сообщение отдельно
  #12 (permalink)  
Старый 11.08.2014, 10:46
Профессор
Посмотреть профиль Найти все сообщения от newobject
 
Регистрация: 10.07.2014
Сообщений: 145

Сообщение от ixth
Откуда у тебя такое тайное знание?
Я просто прикинул логически. Иначе быть не может. Я уже писал: когда начинается цикл он блокирует все, в том числе и пользовательский ввод. Пользователь печатает, но буковы не приходят сразу в инпут, а становятся в очередь, и отобразятся только после выполнения цикла, когда управление вернется к браузеру. Тут самым очевидным решением представляется -- прервать цикл в момент ввода, но пока выполняется цикл он не может получить событие ввода, он занимает единственный поток, и пока он его занимает, события не получаются браузером. Это неразрешимая проблема. Если пускать каждую итерацию отдельным таймаутом, на каждой итерации управление будет таки возвращатся к браузеру, но мы получим медленное выполнение цикла тогда. Отсюда и выводы
Сообщение от ixth
Как видишь, на больших объемах replaceHTML у меня немного быстрее. Судя по jsperf, в других браузерах innerHTML работает еще хуже.
Даже если и так, это копейки. Сравни время обхода в цикле большого массива с проверками и время вставки куска в документ. Это фигня.
Сообщение от ixth
И да, расскажи про машину, на которой все это выполняется.
Я щас на работе, не могу точно сказать. Ноутбук ушатанный, ему лет 8. Помню, что там 2 ядра, оперативы меньше гига, частота меньше 2-х. Процессор -- amd атлон, ЕМНИП. Вот на работе тоже слабая машина, ОЗУ - 1,48, CPU - 2,26, INTEL, не тормозит вообще. Вот, как раз такие вещи удобно тестить на древних слабых машинах, а то бы я и не знал, что хром говно.
Ответить с цитированием