Тормозит java в браузере
Обновлено: 04.07.2024
Крайне медленно стартует и работает(второе только в больших программах) java.
Система: WIndows 8 x64, ОЗУ -7 ГБ, Процессор - Intel Xeon E5440 2.83 GHz.
Нажимаю на файл *.jar - в процессах появляется java platform(tm) se binary, потребляет скромные ресурсы процессора и ОЗУ - видимо что-то делает. Через минут 2-10 (в зависимости от программы) сама программа запускается и работает.
Например, запускаю контрольную панель Java: Панель управления -> Java, и только через 2-3 минуты панель открывается.
Ставил разные версии Java, разрядность - результат такой же.
Кто знает, в чем может быть причина? Ранее запускалось все быстро. Когда произошли изменения не заметил.
__________________Помощь в написании контрольных, курсовых и дипломных работ здесь
Не запускается установленный Kaspersky и очень медленно открываются страницы интернета
Добрый день форумчанам. Такая проблема: 1. На компьютере установлен Касперский Интернет.
Очень медленно запускается Windows после изменения прав доступа к System Volume Information
Много букв, поэтому постарался оформить поудобнее, надеюсь, модератор одобрит. Windows 7 x64.
Без очевидной причины начали очень-очень медленно грузится страницы в браузерах
Без очевидной причины начали очень-очень медленно грузится страницы в браузерах Добавлено через.
Интернет стал очень и очень медленно работать
здравствуйте, установил семерку, ввиду неопытности в познании кибернаук не могу прочувствовать её.
Спасибо за ссылку. Там все на английском - его знаю только с переводчиком.
Насколько понял - в основном там для разработчиков и описаны причины в самих программах, их коде. Но у меня все программы без исключения медленно стартуют. Использую только готовые программы - сам не компилирую.
Если ответ есть по ссылке, может что-то не понял, можно на примере показать: что ,как и где написать, запустить?
Может антивирус пытается что-нибудь провалидировать?Какая загрузка CPU во время старта?
Попробуйте поснимать thread dump-ы раз в секунду для какого-нибудь простенького приложения и приложить их сюда.
Может антивирус пытается что-нибудь провалидировать?
Загрузка CPU до старта и после - 5%, во время старта - 31%.
Прикладываю лог jstack для двух программ + программы и срины дисп. задач до и после старта "JKube":
1. JKube запускается более 2 мин;
2. MD5Calculator11 - запускается с первой секунды.
Программы выбраны случайно.
Аналогичная ситуация, как и с "JKube", возникает при запуске самой панели управления "Java".
Проанализировал логи, и выяснил интересный факт:
1. Программы из архива выше запускаются примерно одинаково (судя по логам)
2.Программа фактически запускается (вижу ее окно), когда в логах jstack появляется поток "D3D Screen Updater" и "DestroyJavaVM".
От чего может зависить запуск этого потока? Что ему не дает запустится раньше?
В Jave не силен, но может кто знающий подскажет?
Эти потоки выполняются очень долго. Что здесь может быть не так?
2017-11-17 18:40:56
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode):
"VM Thread" os_prio=2 tid=0x0000000016a28800 nid=0xe3c runnable
"VM Periodic Task Thread" os_prio=2 tid=0x0000000018628800 nid=0x2698 waiting on condition
Производительность — это один из важнейших вопросов, встающих перед разработчиками веб-страниц или веб-приложений. Никто не будет рад «падающему» от чрезмерной нагрузки приложению, или странице, которая загружается целую вечность. Пользователи веб-сайтов не готовы слишком долго ждать их загрузки или приведения их страниц в рабочее состояние. Согласно данным Kissmetrics, 47% посетителей ожидают, что веб-сайт загрузится менее чем за 2 секунды. 40% посетителей покинут сайт в том случае, если его загрузка займёт более 3 секунд.
Автор материала, перевод которого мы сегодня публикуем, говорит, что, если учитывать вышеприведённые цифры, становится ясно, что производительность — это то, о чём всегда стоит помнить веб-разработчикам. Здесь будут приведены 12 рекомендаций по улучшению производительности JS-проектов.
1. Пользуйтесь кэширующими механизмами браузеров
Скрипты часто используются для организации доступа к определённым объектам. Если хранить ссылку на объект, к которому часто требуется доступ, в переменной, а также если использовать эту переменную в повторяющихся операциях, при выполнении которых требуется доступ к объекту, можно добиться улучшения производительности кода.
2. Оптимизируйте код в расчёте на те среды, в которых он будет выполняться
Для того чтобы адекватно оценивать улучшения, вносимые в программу, рекомендуется сформировать набор сред, в которых можно провести измерения.
На практике вам не удастся выполнять исследования производительности кода, например, во всех существующих версиях JS-движков, равно как и оптимизировать код в расчёте на все среды, в которых он может выполняться. Но надо отметить, что тестирование кода в какой-то одной среде — тоже не лучшая практика. Такой подход может дать искажённые результаты. Поэтому важно сформировать набор сред, в которых, вероятнее всего, будет выполняться код, и тестировать проекты в этих средах.
3. Избавляйтесь от неиспользуемого JS-кода
Благодаря удалению из проекта неиспользуемого кода улучшится не только время загрузки скриптов браузерами, но и время, необходимое браузерам на то, чтобы проанализировать и скомпилировать код. Для того чтобы избавиться от неиспользуемого кода стоит обратить внимание на особенности работы проекта. Так, если вы обнаружили некий функционал, с которым не работают пользователи — рассмотрите возможность убрать его из проекта, а заодно — и связанный с ним JS-код. В результате сайт будет загружаться быстрее, он будет быстрее подготавливаться к работе в браузере. Это благотворно скажется на тех впечатлениях, которые работа с сайтом вызовет у пользователей. Анализируя проект, учитывайте, что, например, некая библиотека, включённая в его состав, может быть включена в него по ошибке. Она вполне может реально в нём не использоваться. От неё стоит избавиться. То же самое касается использования неких зависимостей, которые реализуют то, что уже реализовано в современных браузерах. Как результат, переход на стандартные возможности браузеров, дублируемые этой зависимостью, поможет избавиться от ненужного кода.
4. Экономно расходуйте память
Стоит стремиться к тому, чтобы веб-проекты использовали бы лишь ту память, без которой они абсолютно не в состоянии обойтись. Дело в том, что разработчику нельзя заранее узнать о том, сколько памяти может быть доступно его приложению на некоем устройстве. Если приложение неоправданно использует большие объёмы памяти — это создаёт повышенную нагрузку на механизмы управления памятью браузерного JS-движка. В частности, это касается сборщика мусора. Частые вызовы сборщика мусора приводят к замедлению работы программ. Это негативно влияет на удобство работы с проектом.
5. Используйте механизмы отложенной загрузки для второстепенных скриптов
Пользователи хотят, чтобы веб-страницы загружались бы как можно быстрее. Но вряд ли для начального отображения страницы нужен абсолютно весь JS-код проекта. Если пользователю, чтобы задействовать некий код, нужно выполнить какое-то действие (например, щёлкнуть по некоему элементу или перейти на какую-нибудь вкладку в приложении), то загрузку этого кода можно отложить, выполнив её после первоначальной загрузки страницы и самых важных ресурсов.
При таком подходе можно избежать загрузки и компилирования браузером большого объёма JS-кода в самом начале работы, то есть — избежать замедления вывода страницы, вызванного необходимостью выполнения этих операций. После того, как завершится загрузка всего самого важного, можно начать загружать дополнительный код. В результате, когда этот код понадобится пользователю, он уже будет ему доступен. В соответствии с моделью RAIL Google рекомендует выполнять сеансы отложенной загрузки скриптов длительностью порядка 50 мс. При таком подходе операции по загрузке кода не повлияют на взаимодействие пользователя со страницей.
6. Избегайте утечек памяти
Если в вашем приложении случилась утечка памяти, то это выразится в том, что загруженная страница будет запрашивать у браузера всё больше и больше памяти. В результате потребление памяти этой страницей может достичь такого уровня, что это плохо повлияет на производительность всей системы. Вероятно, вы и сами сталкивались с подобной проблемой (и вам это, наверняка, не понравилось). Вполне возможно, что страница, на которой имелась утечка памяти, содержала некое средство просмотра изображений — вроде слайдера или «карусели».
В инструментах разработчика Chrome можно проанализировать сайт на предмет утечек памяти. Делается это путём исследования показателей средствами вкладки Performance. Обычно утечки памяти исходят из-за фрагментов DOM, удалённых со страницы, но привязанным к каким-то переменным. Это не позволяет сборщику мусора очистить память, занимаемую данными ненужными фрагментами DOM.
7. Если вам нужно выполнить некие тяжёлые вычисления — используйте веб-воркеры
Из материалов ресурса MDN можно узнать о том, что веб-воркеры позволяют запускать код в фоновом потоке, отделённом от главного потока веб-приложения. Преимущество такого подхода заключается в том, что тяжёлые вычисления могут быть выполнены в отдельном потоке. Это позволяет главному потоку (обычно ответственному за обеспечение работы пользовательского интерфейса) выполняться без блокировок и замедлений.
Веб-воркеры позволяют выполнять вычисления, интенсивно использующие процессор, и при этом не блокировать поток пользовательского интерфейса. Эта технология позволяет создавать новые потоки и давать им задания, что благотворно сказывается на производительности приложения. При таком подходе задачи, на выполнение которых требуется много времени, не блокируют выполнение других задач. При выполнении подобных задач в главном потоке выполнение других задач блокируется.
8. Если вы обращаетесь к элементу DOM несколько раз — сохраните ссылку на него в переменной
Получение ссылки на элемент DOM — операция медленная. Если вы собираетесь обращаться к элементу несколько раз — лучше всего сохранить ссылку на него в локальной переменной. Но тут важно помнить о том, что если элемент, ссылка на который хранится в переменной, будет позже из DOM удалён, нужно убрать из переменной и ссылку на него. Например, сделать это можно, записав в переменную значение null . Это позволит избежать утечек памяти.
9. Стремитесь объявлять переменные в той же области видимости, в которой они будут использоваться
JavaScript, при попытке доступа к переменной, сначала ищет её в локальной области видимости. Если её там не оказывается — поиск продолжается в областях видимости, в которую вложена локальная область видимости. Так происходит до тех пор, пока проверке не подвергнутся глобальные переменные. Сохранение переменных в локальных областях видимости ускоряет доступ к ним.
Постарайтесь, без особой необходимости, не использовать при объявлении переменных ключевое слово var . Используйте вместо него, для объявления, соответственно, переменных и констант, ключевые слова let и const . Они отличаются блочной областью видимости и некоторыми другими полезными особенностями. Внимательно относитесь к использованию переменных в функциях, стремясь к тому, чтобы переменные, к которым вы обращаетесь внутри функции, были бы для неё локальными. Помните о неприятностях, которые может вызвать неявное объявление глобальных переменных.
10. Старайтесь не использовать глобальные переменные
Глобальные переменные существуют в течение всего времени работы скрипта. Локальные же переменные уничтожаются при уничтожении локальной области видимости. Поэтому глобальными переменными стоит пользоваться лишь тогда, когда это действительно необходимо.
11. Применяйте в JavaScript оптимизации кода, которые вы применяли бы и к программам, написанным на других языках
- Всегда применяйте алгоритмы с наименьшей из возможных вычислительной сложностью, решайте задачи с использованием оптимальных структур данных.
- Оптимизируйте используемые алгоритмы, стремясь получить те же результаты, выполнив меньше вычислений.
- Избегайте рекурсивных вызовов.
- Оформляйте повторяющиеся фрагменты вычислений в виде функций.
- Упрощайте математические вычисления.
- Используйте поисковые массивы вместо конструкций switch/case.
- Стремитесь к тому, чтобы условия, проверяемые в условных конструкциях, чаще принимали бы истинные значения. Это способствует более эффективному использованию возможностей процессора по упреждающему исполнению команд.
- Если у вас есть возможность использовать для выполнения неких действий побитовые операторы — сделайте это. На выполнение подобных вычислений уходит меньше ресурсов процессора.
12. Используйте инструменты для исследования производительности приложений
Для исследования различных аспектов веб-проектов можно порекомендовать инструмент Lighthouse. Он выставляет приложению оценки по следующим показателям: Performance, Progressive Web App, Accessibility, Best Practices, SEO. Lighthouse не только выставляет оценки, но и даёт рекомендации по улучшению проекта. Ещё одно средство для анализа производительности, Google PageSpeed, создано для того, чтобы помочь разработчикам исследовать свои сайты и увидеть направления их возможного улучшения.
И Lighthouse, и PageSpeed — инструменты не идеальные, но их использование помогает увидеть проблемы, которые, на первый взгляд, могут оказаться незаметными.
В меню Chrome можно найти команду, открывающую диспетчер задач. Там выводятся сведения о системных ресурсах, используемых открытыми вкладками браузера. Более подробные сведения о том, что происходит на странице, можно получить, открыв вкладку Performance инструментов разработчика Chrome (подобные инструменты есть и в других браузерах). Эта вкладка позволяет анализировать множество показателей, касающихся производительности сайта.
Вкладка Performance в инструментах разработчика Chrome
В ходе сбора сведений о производительности страниц средствами Chrome можно настраивать доступные страницам процессорные и сетевые ресурсы, что позволяет выявлять и исправлять проблемы.
Анализ производительности страницы в Chrome
Для того чтобы глубже проанализировать веб-сайт — можно воспользоваться API Navigation Timing. Оно позволяет выполнять измерения различных показателей прямо в коде приложения.
Если вы разрабатываете на JavaScript серверные проекты с использованием Node.js, то вам, для глубокого анализа своих приложений, можно воспользоваться платформой NodeSource. Измерения, проводимые средствами этой платформы, оказывают незначительное воздействие на проект. В среде Node.js, как и в браузере, может возникать множество проблем — вроде тех же утечек памяти. Анализ проектов, основанных на Node.js, помогает выявлять и устранять проблемы с их производительностью.
Итоги
Важно поддерживать баланс между оптимизацией кода и его читабельностью. Код интерпретируется компьютером, но поддерживать его приходится людям. Поэтому код должен быть понятным не только компьютеру, но и человеку.
Кроме того, полезно помнить о том, что производительность стоит принимать в расчёт всегда, но она не должна быть важнее обеспечения безошибочной работы кода и реализации нужных пользователям возможностей приложений.
Даже на FX-6300 4400 МГц ничего не свистит и не пердит. Мне нужно именно ускорить, так как убогие кодеры на 95% сайтах не могут отобразить содержание сайта корректно без джавы.
Вот Яркий пример. Это каким же дегенератом надо быть, чтобы не суметь вывести текст, без наличия ЖС?
так джаву или джаваскрипт? ;) ты уж определись, чего ускорять собрался?!
Что то ту не так.
ты текст то иногда пробуй читать полностью. Кто тебе сказал, что я хочу её отключить?
Gentoo, www-client/chromium-36.0.1985.103, всё открывается быстро.
Ну и там не Java, а javascript.
Кактус рядом поставить.
разве javascript это не облегчённая java? синтаксис же из java пришёл
Вот Яркий пример. Это каким же дегенератом надо быть, чтобы не суметь вывести текст, без наличия ЖС?
Зачем это в твоём вопросе?
Хотя ладно, тут спорить о формулировку вопроса можно долго с переходом на личности в итоге, оно нам надо? Нет конечно ::)
А по делу, сомневаюсь что можно как то это сделать, хотя чёрт его знает.
Вот Яркий пример. Это каким же дегенератом надо быть, чтобы не суметь вывести текст, без наличия ЖС?
Будучи школьником ваял некую страничку на голом HTML'е, где зона с контентом была отдельным фреймом, а все остальное вокруг отдельно, и никогда не обновлялось при переходах по страничкам, было здорово. Может здесь что то подобное.
но ведь они так похожи на jvm тоже есть javascript, такая java без явного указания типов.
А ещё все языки похожи на C, PHP, Pascal, Python, Ruby . потому, что там есть if, for, прочее.
javascript - это скриптовый язык, который обрабатывается напрямую в браузере.
java вставки обрабатываются java, в вашей системе должна быть установлена java машина, а в браузере подключен java плагин, затем код написанный на java транслируется в байт код и выполняется в виртуальной java машине (jvm).
Без разницы, что синтаксис похож.
Общим заблуждением является то, что JavaScript аналогичен или тесно связан с Java, это не так[19]. Оба языка имеют C-подобный синтаксис, являются объектно-ориентированными и как правило широко используются в клиентских веб-приложениях, на этом их сходство заканчивается:
Вопрос из хёдера остаётся открытым.
Там нет адекватного вопроса. Если тебя что-то не устраивает - не заходи на этот сайт.
А так меняй браузер, если у тебя проблема с производительностью javascript.
kostik87 ★★★★★ ( 28.11.14 11:21:11 )Последнее исправление: kostik87 28.11.14 11:25:20 (всего исправлений: 1)
Нененене ты что, чур меня чур, вот крест тебе восьмиугольный ::)
а что, у разных браузеров принципиально иной (Тм) жс-движок?
Как ты умудряешься быть таким беспросветно невежественным? Во всем, куда только не сунешься?
Даже на FX-6300 4400 МГц ничего не свистит и не пердит.
Что? Мне так и хочется перейти на личности. Скорее всего твои претензии есть просто потому, что на ЛОРе модно ругать JS. Ну и цепляться за всякие мелочи, которые ну вообще никому не надо. Или работу тормозит что-то другое, а ты списываешь это на JS. У меня все летает и на гораздо менее производительном железе (на многих машинах при чем).
Это каким же дегенератом надо быть, чтобы не суметь вывести текст, без наличия ЖС?
Просто JS в некоторых случаях облегчает программисту работу, да. И скорее всего разработчики сайта не ориентировались на три с половиной пользователя ЛОРа, когда делали сайт.
Ты путаешь джаву и джаваскрипт, и когда тебе говорят, что они разные, утверждаешь что они не разные, ведь у них синтаксис похожий. Это вызывает еще больше желания перейти на личности.
Си шарп и Джава тоже имеют похожий синтаксис.
Мне нужно именно ускорить, так как убогие кодеры на 95% сайтах не могут отобразить содержание сайта корректно без джавы.
.
Это каким же дегенератом надо быть, чтобы не суметь вывести текст, без наличия сишарпа?
Попробовал сравнить программы, вычисляющие число пи, написанные на C и Java. Использовал Ряд Лейбница. Вот что получилось:
Java (JRE 1.6): 18 с
C (gcc 4.4.3 с -O2): 24 c
PS. Я C программист, к яве отношения не имею :)
> int … i
> i <= 2000000000
> i*2
> Я C программист
А что не так с этим? Ъ-насильники пользуются только битовым сдвигом?
Можешь замерить Java программу с ключами -server -Xbatch?
Я помню когда-то простой цикл с суммирование так тестировал. Круче всех пошутила MSVS, посчитав цикл на этапе компиляции)
> А что не так с этим?
2000000000 * 2 < 0
да по хорошему бы там надо писать i+=2 а вместо умножения на z разбить на два цикла с разными знаками, но на фоне затрат на деление это все мелочи.
Переполнение инта вряд ли сильно изменит ответ, на хвосте то знакопеременного ряда.
Тест забавный. может ява сама его запараллелила? ;-)
Да. Запусти эклипсу и убедись.
Хотя и косяк, но на скорость не влияет
Ясно, не посмотрел контекст.
My bad, sorry :-) Увеличивал счетчик, а про int-то забыл, ага
Стало чуть быстрее (0.5с). В пределах погрешности.
в данном случае интересно было бы посмотреть на результат icc, как говорят на таких задачах он как раз и дает форы gcc
А теперь -client -Xbatch, плз.
И еще нюанс. Как ты меряешь? Нужно таймером мерять промежуток выполенияк кода, иначе включаешь во время запуск JVM, а это дофига.
Java тормозит?
Да. Запусти эклипсу и убедись.
Эклипс как раз не особо и тормозит. Он же не на Swing. Вот нетбинс, тот да.
> Java (JRE 1.6): 18 с
> C (gcc 4.4.3 с -O2): 24 c
одна из черепашек врёт ;)
> А теперь -client -Xbatch, плз.
Да то же самое. Чуть меньше 18с
И еще нюанс. Как ты меряешь? Нужно таймером мерять промежуток выполенияк кода, иначе включаешь во время запуск JVM, а это дофига.
Ручным секундомером :) Может и смешно, но, увидев такую разницу в первоначальном варианте, решил, что и так нормально. Сейчас попробую замерить по-хорошему.
Ты что шутишь, нормально? Java должна работать в два раза быстрее.
> Нужно таймером мерять промежуток выполенияк кода
По 3 попытки на каждый вариант. В миллисекундах:
17395, 17396, 17402
java -server -Xbatch Main
17508, 17408, 17416
java -client -Xbatch Main
17466, 17403, 17408
Ну толсто же, ну. Там баян, а тут пила. Как можно сравнивать то?
А включен ли в GCC Graphite Loop Optimizaions?
А если включен, поменяется ли результат, если декларацию i внести внутрь цикла, так же, как в Java (разрешено в C99)?
Но это моё личное, субъективное, мнение. Пруфов нет. И не будет.
А включен ли в GCC Graphite Loop Optimizaions? А если включен, поменяется ли результат, если декларацию i внести внутрь цикла, так же, как в Java (разрешено в C99)?
Попробовал включить. Всё едино:
говно ваша джава! аминь
ты запихнул в инт 2000000000? ауч.
> ты запихнул в инт 2000000000? ауч.
У меня gcc-4.6. Если компилировать с -O3 - то примерно также. Но если сделать -Ofast - результат одинаков в пределах погрешности.
да по хорошему бы там надо писать i+=2 а вместо умножения на z разбить на два цикла с разными знаками, .
. и получить накопление ошибок — каждая сумма будет больше пи/4 примерно в ln 1 000 000 000
З.Ы. тут можно и i+=4, но компилятор должен до этого догадаться, не?
double i важно потому чтобы избежать дорогоих int -> double кастов
кстати говоря, все посчитанные числа в этом треде не соответствуют числу пи:
pi = 3.141592653589793238462643.. proof
компилятор явы, если не указать иное, ничего оптимизировать не будет
И никто не осилил собрать с PGO.
> кстати говоря, все посчитанные числа в этом треде не соответствуют числу пи
переполнение инта, че
а вообще должны соответствовать с точностью до 1/ 4 000 000 000
насчет кастов, наверно, соглашусь
а вот насчет точности — ты тоже теряешь один десятичный знак (хотя это и не будет видно при i<10^15)
умел бы sse double можно было бы это еще в 4 раза быстрее сделать
А как насчет распараллелить для CUDA и посчитать на среднебюджетной видеокарте (тысячи за 3-4 деревянных)?
нужно собрать кластер.
Не, давайте уж на среднестатистическом домашнем компьютере считать. Стоимостью порядка килобакса.
Да, давайте доказывать, что ява тормозит, используя gpgpu и ручные оптимизации на ассемблере)
Ну как вам доказать, что ява тормозит? ИМХО вы не принимаете, а объективных тестов не существует (т.к. они сильно зависят от платформы, версии ява-глюконавта и фазы Луны).
Не нужно ничего доказывать.
Ява имеет известный оверхед на некоторых операциях, и это очевидно. Применяется она традиционно в таких задачах, для которых этот оверхед совсем не критичен.
Но это не значит, что любая программа, написанная на яве будет тормозить на порядок больше такой же на с++.
Кроме того, jit сильно ускоряет тяжелые для интерпретации операции (вызов через интерфейс, чтение/запись поля, например).
Реальные приложения, имеющие больше логики, чем вычислений, программа тормозит из-за программиста, а не из-за сборщика мусора.
2 ядра. java юзает оба.
программа тормозит из-за программиста, а не из-за сборщика мусора.
Да ладно вам, говорите уж прямо: ява, как и дерьмомоно, была придумана для написания кроссплатформенных легких игрулек, или же элементарных граф-морд. И ни для чего другого не годится.
java — тормоз. Она на двух ядрах работает 11 секунд, программа на C — 14 секунд на одном ядре.
nvidia g105m (8 cores), интегрирование четверти окружности методом трапеций
В то время, когда она была придумана, игры и фронтенды на ней точно писать не предполагалось.
А вот на серверных задачах ява все еще один из лидирующих языков.
Читайте также: