Комментарии 21
Спасибо за отзыв,
тестировал на крупных проектах, в целом код замедляется незначительно, еще сильно зависит от настройки, в частности сбора данных во время выполнения (параметры функций, возвращаемые значения). Можно посмотреть совет по получению наилучшей производительности в примере конфигурационного файла.
тестировал на крупных проектах, в целом код замедляется незначительно, еще сильно зависит от настройки, в частности сбора данных во время выполнения (параметры функций, возвращаемые значения). Можно посмотреть совет по получению наилучшей производительности в примере конфигурационного файла.
0
Что может быть не совсем быстрым — это начальная инструментация больших js файлов (таких как большие библиотеки). Но, один раз инструментированный ресурс кэшируется и последующие разы все работает быстрее. В примере конфигурационного файла указано как можно не инструментировать (и соответственно не трейсить) файлы, которые неинтересны в данный момент (например библиотеки, утилиты и прочее). Так и шума меньше и работает шустрее.
0
Вроде код открытый. После деобфускации и небольшого рефакторинга имён переменных вполне читаемо.
0
Код проекта не является открытым (то есть это, как минимум в настоящий момент, бесплатный, но не open source проект), но так как это JavaScript, то закрыть/защитить его сложно чем-то большим, чем указанием в коде:
* Using/copying/sharing/distributing the code in any way
* (different from licensed product usage described in EULA)
* is not allowed without owner's written permission.
Если есть интерес, могу написать более подробную статью, с примерами не минифицированного кода с нормальными именами переменными.
* Using/copying/sharing/distributing the code in any way
* (different from licensed product usage described in EULA)
* is not allowed without owner's written permission.
Если есть интерес, могу написать более подробную статью, с примерами не минифицированного кода с нормальными именами переменными.
+1
Интересно. Хотелось бы подробнее узнать об этих самых инструментационных инструкциях, ведь в них, я так понимаю, вся магия.
0
Я подумываю написать более подробную техническую статью с описанием технологии. Пока можете просто нажать F12 в браузере с профилируемой страницей и посмотреть каким образом ваш код модифицирован. Похожим образом работают всевозможные открытые code coverage библиотки для javascript (istanbul, jscover и другие).
0
Замечательная работа. Почему только, в дереве вызовов показываются лишь события? Или точнее сказать, каждый новый event loop. Имея много асинхронного кода, становится довольно сложно ориентироваться в списке, так как становится много
И почему не «трейсятся» консольные вызовы —
Есть ли в планах сделать cpu статистику функций? И версию для node.js приложений (
Ну и в конце концов, больше подробностей с примерами не помешало бы… )
readystate/timeout/otherGenericListener
. Собственно, хотелось бы иметь поиск также в списке с событиями, что бы искать нужную функцию.И почему не «трейсятся» консольные вызовы —
myLib.doSmth();
, хотя просматривая myLib.doSmth;
видно, что все метки проставлены шпионом ). Есть ли в планах сделать cpu статистику функций? И версию для node.js приложений (
$ spy myapp.js
)?Ну и в конце концов, больше подробностей с примерами не помешало бы… )
0
Спасибо за отзыв и комментарии по использованию.
В примере конфигурационного файла описано как можно фильтровать события. Запрос на фичу по поиску создал на github, посмотрите пожалуйста это ли имелось ввиду под поиском в событиях?
Насчет консольных вызовов, посмотрел — они трейсятся, но неверно записываются в последнее событие и еще портят время выполнения события (завел баг). Пока как workaround можно просто еще раз нажать на последнее событие и консольны вызов будет в конце.
Насчет появления в планах той или иной вещи — у меня есть конкретное видение и большой список того, что еще я бы хотел добавить. Список этот я опубликую постепенно создавая issues в репозитории проекта на github и в roadmap. Пожелания пользователей естественно обладают повышенным приоритетом, поэтому пожалуйста плюсуйте/создавайте запросы на фичи на github (позже подключу что-нибудь более специализированное, вроде uservoice или tenderapp).
Можете пояснить что подразумевается под cpu статистикой функций?
Версия для node в планах есть, «фича» немаленькая, зависит от того сколько людей захочет такую возможность.
Документацию пополняю почти ежедневно, так что скоро с подробностями будет лучше.
В примере конфигурационного файла описано как можно фильтровать события. Запрос на фичу по поиску создал на github, посмотрите пожалуйста это ли имелось ввиду под поиском в событиях?
Насчет консольных вызовов, посмотрел — они трейсятся, но неверно записываются в последнее событие и еще портят время выполнения события (завел баг). Пока как workaround можно просто еще раз нажать на последнее событие и консольны вызов будет в конце.
Насчет появления в планах той или иной вещи — у меня есть конкретное видение и большой список того, что еще я бы хотел добавить. Список этот я опубликую постепенно создавая issues в репозитории проекта на github и в roadmap. Пожелания пользователей естественно обладают повышенным приоритетом, поэтому пожалуйста плюсуйте/создавайте запросы на фичи на github (позже подключу что-нибудь более специализированное, вроде uservoice или tenderapp).
Можете пояснить что подразумевается под cpu статистикой функций?
Версия для node в планах есть, «фича» немаленькая, зависит от того сколько людей захочет такую возможность.
Документацию пополняю почти ежедневно, так что скоро с подробностями будет лучше.
0
Под cpu статистикой имел ввиду «cpu profiling». Сколько мс выполняется сама функция и её цепочки выше по стеку, как у вас на скриншоте из dev tools.
Думаю, для nodejs будет такая вещица даже более востребована, так как нормального профилирования (не через пень-колоду) так и не нашел. Довольно легко сделать аналог require и подменять оригинал, так что бы все скрипты после загрузки, обзаводились метками и исполнялись. Ну a используя socket.io, данные бы отсылались на локальный сервер и был виден результат в браузере.
Думаю, для nodejs будет такая вещица даже более востребована, так как нормального профилирования (не через пень-колоду) так и не нашел. Довольно легко сделать аналог require и подменять оригинал, так что бы все скрипты после загрузки, обзаводились метками и исполнялись. Ну a используя socket.io, данные бы отсылались на локальный сервер и был виден результат в браузере.
+1
Некоторые работы по поддержке node.js велись и ведутся (пока все на этапе прототипирования, но прогресс есть). Если удобно, плюсуйте за фичу на github, также подписывайтесь на твиттер, я обязательно буду сообщать о прогрессе этой и других фич.
0
Вышла новая версия 0.1.6, документация значительно пополнена примерами и подробностями, реализована локальная proxy без необходимости менять системные настройки.
0
Спасибо, инструмент очень понравился. Можно ли как-то дампить объекты типа Date (дампится пустой объект)?
0
Спасибо за отзыв и замечание. Завел issue, будет в следующем релизе. Создавайте новые issue на github если удобно.
+2
Не получилось скачать —
«Диск Google
Приложение в настоящий момент недоступно.» :( А так выглядит заманчиво, хотя и не глубокий спец в js.
«Диск Google
Приложение в настоящий момент недоступно.» :( А так выглядит заманчиво, хотя и не глубокий спец в js.
0
А почему вы не хотите выложить исходники? Может быть с помощью сообщества дело пошло бы гораздо быстрее и продуктивнее? Или есть конкретная цель — заработать?
+1
Цель развить успешный бизнес есть. Конкретных планов будет это осуществляться с открытыми или закрытыми исходниками пока нет. Если это будет путь crowd-funding-а или платной поддержки, то исходники вполне могут быть открыты, если продажа лицензий, то открывать исходники невыгодно. Я рассматриваю варианты, на данный момент интересно понять потребность и объемы аудитории. Пока склоняюсь к идее продаже лицензий, но только потому что это выглядит проще и более менее обкатаный путь.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JavaScript трассировка, отладка, профилирование – заполнение пробелов