Pull to refresh

Comments 21

Очень круто.
Как насчет реакции и не сильно-ли замедляется исходный код?

P.S. traceGL в этом плене очень шустрый, но под Mac OS он не работает из-за драйверов ATI.
Спасибо за отзыв,

тестировал на крупных проектах, в целом код замедляется незначительно, еще сильно зависит от настройки, в частности сбора данных во время выполнения (параметры функций, возвращаемые значения). Можно посмотреть совет по получению наилучшей производительности в примере конфигурационного файла.
Что может быть не совсем быстрым — это начальная инструментация больших js файлов (таких как большие библиотеки). Но, один раз инструментированный ресурс кэшируется и последующие разы все работает быстрее. В примере конфигурационного файла указано как можно не инструментировать (и соответственно не трейсить) файлы, которые неинтересны в данный момент (например библиотеки, утилиты и прочее). Так и шума меньше и работает шустрее.
Вроде код открытый. После деобфускации и небольшого рефакторинга имён переменных вполне читаемо.
Код проекта не является открытым (то есть это, как минимум в настоящий момент, бесплатный, но не 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.

Если есть интерес, могу написать более подробную статью, с примерами не минифицированного кода с нормальными именами переменными.
Да это я понял, просто забавно в случае жс слышать о том что код закрыт. Интерес есть, но скорее не к коду, а к концептуальному подходу модификации жс кода. Хотя это можно и руками раскрутить, но хотелось бы почитать про грабли, встреченные на пути, и методы их решений.
Интересно. Хотелось бы подробнее узнать об этих самых инструментационных инструкциях, ведь в них, я так понимаю, вся магия.
Я подумываю написать более подробную техническую статью с описанием технологии. Пока можете просто нажать F12 в браузере с профилируемой страницей и посмотреть каким образом ваш код модифицирован. Похожим образом работают всевозможные открытые code coverage библиотки для javascript (istanbul, jscover и другие).
Замечательная работа. Почему только, в дереве вызовов показываются лишь события? Или точнее сказать, каждый новый event loop. Имея много асинхронного кода, становится довольно сложно ориентироваться в списке, так как становится много readystate/timeout/otherGenericListener. Собственно, хотелось бы иметь поиск также в списке с событиями, что бы искать нужную функцию.

И почему не «трейсятся» консольные вызовы — myLib.doSmth();, хотя просматривая myLib.doSmth; видно, что все метки проставлены шпионом ).

Есть ли в планах сделать cpu статистику функций? И версию для node.js приложений ($ spy myapp.js)?

Ну и в конце концов, больше подробностей с примерами не помешало бы… )
Спасибо за отзыв и комментарии по использованию.

В примере конфигурационного файла описано как можно фильтровать события. Запрос на фичу по поиску создал на github, посмотрите пожалуйста это ли имелось ввиду под поиском в событиях?

Насчет консольных вызовов, посмотрел — они трейсятся, но неверно записываются в последнее событие и еще портят время выполнения события (завел баг). Пока как workaround можно просто еще раз нажать на последнее событие и консольны вызов будет в конце.

Насчет появления в планах той или иной вещи — у меня есть конкретное видение и большой список того, что еще я бы хотел добавить. Список этот я опубликую постепенно создавая issues в репозитории проекта на github и в roadmap. Пожелания пользователей естественно обладают повышенным приоритетом, поэтому пожалуйста плюсуйте/создавайте запросы на фичи на github (позже подключу что-нибудь более специализированное, вроде uservoice или tenderapp).

Можете пояснить что подразумевается под cpu статистикой функций?
Версия для node в планах есть, «фича» немаленькая, зависит от того сколько людей захочет такую возможность.
Документацию пополняю почти ежедневно, так что скоро с подробностями будет лучше.
Под cpu статистикой имел ввиду «cpu profiling». Сколько мс выполняется сама функция и её цепочки выше по стеку, как у вас на скриншоте из dev tools.

Думаю, для nodejs будет такая вещица даже более востребована, так как нормального профилирования (не через пень-колоду) так и не нашел. Довольно легко сделать аналог require и подменять оригинал, так что бы все скрипты после загрузки, обзаводились метками и исполнялись. Ну a используя socket.io, данные бы отсылались на локальный сервер и был виден результат в браузере.
Некоторые работы по поддержке node.js велись и ведутся (пока все на этапе прототипирования, но прогресс есть). Если удобно, плюсуйте за фичу на github, также подписывайтесь на твиттер, я обязательно буду сообщать о прогрессе этой и других фич.
Спасибо, инструмент очень понравился. Можно ли как-то дампить объекты типа Date (дампится пустой объект)?
Спасибо за отзыв и замечание. Завел issue, будет в следующем релизе. Создавайте новые issue на github если удобно.
Не получилось скачать —
«Диск Google
Приложение в настоящий момент недоступно.» :( А так выглядит заманчиво, хотя и не глубокий спец в js.
А почему вы не хотите выложить исходники? Может быть с помощью сообщества дело пошло бы гораздо быстрее и продуктивнее? Или есть конкретная цель — заработать?
Цель развить успешный бизнес есть. Конкретных планов будет это осуществляться с открытыми или закрытыми исходниками пока нет. Если это будет путь crowd-funding-а или платной поддержки, то исходники вполне могут быть открыты, если продажа лицензий, то открывать исходники невыгодно. Я рассматриваю варианты, на данный момент интересно понять потребность и объемы аудитории. Пока склоняюсь к идее продаже лицензий, но только потому что это выглядит проще и более менее обкатаный путь.
Sign up to leave a comment.

Articles

Change theme settings