Mam dużą, ciężką aplikację javascript, nad którą pracuję. Mam bardzo krótkie czasy reakcji z narzędzi Chrome Dev dla odpowiedzi XHR i logowania do konsoli (3-5 s). Rzeczywista aplikacja działa szybko i reaguje, tylko narzędzia programisty mają wrażenie, że cierpi.Narzędzia deweloperskie Chrome bardzo wolno reagują na dużą aplikację internetową
Czy ktoś ma pojęcie, dlaczego narzędzia Chrome Dev stają się coraz wolniejsze, gdy moja aplikacja rośnie?
Devtools są jak każdy inny debugger; przechwytują one normalny przepływ przetwarzania aplikacji i przechowują dość dużo więcej informacji, niż jest to zwykle wymagane. To znacznie więcej pracy niż zwykłe renderowanie strony bez włączonego debugowania, więc będzie wolniej.
To powiedziawszy, 3 sekundy na odpowiedź na console.log wydaje się wysokie. Proponuję najpierw przetestować aplikację pod numerem nightly version of WebKit. Jeśli jest responsywny w WebKit, ale nie w Chrome, zgłoś błąd inspektorowi poprzez http://new.crbug.com/ wraz z wszelkimi informacjami, które możesz podać, o tym, który scenariusz powoduje spowolnienie.
Jeśli to równie powolny w WebKit, proszę zgłosić błąd przeciwko komponentu Inspector oprogramowania WebKit: https://bugs.webkit.org/enter_bug.cgi
czy inaczej, dodawać identyfikator błędu tutaj, a ja zobaczę, że to przyporządkowani do właściwego zespołu.
Firefox/Firebug reagują znacznie lepiej podczas debugowania tej samej dużej strony, którą dławi się Chrome. I uwielbiam Chrome! –
To jest stare pytanie, ale może pomóc komuś lądując tutaj później tak jak ja.
Korzystanie z Chrome 46.x/47.x na Linuksie (RHEL 7), żadne z proponowanych rozwiązań nie sprawdziło się u mnie. Pracowało się nad wyłączeniem ustawienia "Użyj akceleracji sprzętowej, gdy jest dostępna", w zaawansowanych ustawieniach przeglądarki.
Zauważyłem na monitorze/liście procesu, że renderer do Chrome zajmował dużo CPU, nawet umieszczenie punktu przerwania lub przejrzenie instrukcji w debugerze zajmie 10 sekund!
Może być wart strzały.
Nie publikuj odpowiedzi dotyczących wyłącznie linków do innych pytań związanych z przepełnieniem stosu. Zamiast tego głosuj/oznacz, by zamknąć jako duplikat, lub, jeśli pytanie nie jest duplikatem, dostosuj odpowiedź do tego konkretnego pytania. –
OK, czy powinienem otrzymać odpowiedź w całości? Nie jest to dokładnie duplikat i jest już powiązany z drugim pytaniem. – AsGoodAsItGets
Jest połączony, ponieważ opublikowałeś tutaj link, rozłączy się, gdy usuniesz odpowiedź, o której myślę. Może lepiej skopiować odpowiedź, ale ją edytować, aby była dobrze dopasowana tutaj –
Oddokuj narzędzia programistyczne w osobnym oknie. W moim przypadku to jest praca.
umysł do opracowania? – manetsus
Zmagałem się z tym również, do tego stopnia, że przechodzenie przez kod przy użyciu chromowanego debuggera było tak powolne, że zajęło mi to wiele godzin z mojego produktywnego czasu rozwoju. Obserwując wykorzystanie procesora podczas debugowania w chrome, zauważyłbym, że zużywa on aż do 40% wszystkich 4 rdzeni mojego procesora. Próbowałem wszystkiego bezskutecznie. Wreszcie, próbowałem uczynić okno przeglądarki strony, którą debugowałem, tak małą, jak tylko mogłem, nie tracąc żadnego z wymaganych widoków i w cudowny sposób rozwiązałem problem. Tak więc, teraz moje okno debuggera wyświetla się w osobnym oknie i sprawia, że okno strony, którą debuguję, jest tak małe, jak tylko mogę i moje doświadczenie w debugowaniu jest bardzo szybkie. Testowałem to przez okres kilku tygodni i to się wydarzyło. Mam nadzieję, że to pomaga komuś.
I „stałe” powolne narzędzie chrom programisty (w zakładce ŹRÓDEŁ)
Nie wiesz, który z obu popełnił największą różnicę, ale na pewno to różnicy
Jestem obecnie przeżywa ten problem podczas pracy z Dojo. Dziwne jest to, że dzieje się tak tylko w skompresowanej wersji Dojo. Praca z wersją źródłową działa dobrze. Sądziłem, że problem powinien wystąpić na odwrót. – Marcelo