В целом мы пытаемся добиться ситуации, в которой значимые деградации просто не могут вмёрджиться. Для этого у нас есть performance-тесты, которые динамически подбирают оптимальное количество итераций (в докладе я как раз про это рассказываю). Для пущей уверенности тесты перезапускаются на нескольких машинах, чтобы гарантированно избежать ложноположительных результатов.
Но вы правы в том, что такие тесты не всегда спасают от регрессий. Пожалуй, самая главная проблема в том, что таких тестов не очень много (т.к. они очень долго идут), покрыты только наиболее критичные сценарии. Поэтому есть система мониторинга, которая шлёт в Slack разнообразные нотификации об уже замёрдженных деградациях. Какого-то красивого универсального подхода к таким проблемам нет, мы просто разбираем все проблемы вручную и пытаемся найти наиболее правильное решение. Обычно, оно попадает в одну из следующих категорий:
Преднамеренная деградация (например, security fix или новая фича, за которую мы все вместе согласились заплатить производительностью): ничего не делаем
Непреднамеренная незначительная деградация: чаще всего нет смысла тратить время на расследование, ничего не делаем
Непреднамеренная значительная деградация:
Если легко откатить — вмёрдживаем revert commit, после чего спокойно разбираемся в проблеме
Если сложно откатить — подключаем всех релевантных разработчиков и пытаемся максимально оперативно пофиксить проблему
По сути, починка вмёрдженной performance-регрессии не особо отличается от починки вмёрдженной обычной регрессии по функциональности: либо откатываем, либо фиксим прямо в master-ветке. Насколько мне известно, принципиально других подходов в индустрии пока не появилось. Единственное отличие performance-регрессий в том, что от них чаще можно отмахнуться и сказать “ну и ладно, не так уж и медленно оно работает, у нас и поважнее задачи есть”, но нужно глубокое понимание продукта для того, чтобы определить ситуации, в которых так сказать действительно можно.
Красивого способа нет и не будет. Я считаю, что это методологически неправильно смотреть только на значения Mean/Median без Error/StdDev. По такой табличке очень опасно делать выводы, т.к. невозможно прикинуть есть ли статистически значимая разница между бенчмарками. Можно легко обмануть себя и другие людей, которые будут смотреть на результаты подобных экспериментов.
Но если очень-очень хочется, то сделать это всё-таки можно. Нужно скопипастить дефолтный конфиг и поменять реализацию GetColumnProviders (вот тут можно посмотреть что подставляется по дефолту).
Такой фичи нет, но она выглядит интересной, можно сделать. Буду рад тикету или пул-реквесту.
Библиотека простая в использовании, но если вдруг её авторы читают сей пост, прошу, дайте более удобную возможность влиять на структуру таблицы результатов.
Раздел «Содержание доклада на 20-30 пунктов» появился не от хорошей жизни. Раньше в 95% случаев спикеры присылали очень короткое описание (иногда буквально в одно предложение), из которого не особо понятно о чём пойдёт речь в докладе. И практически всегда общение со спикером начиналось со слов «А можете поподробнее расписать о чём доклад?». Поэтому мы добавили такую формулировку в форму. Если пунктов будет меньше 20, то заявку всё равно можно отправить, это лишь рекомендуемый объём (который в большинстве случаев экономит всем время). Спасибо за фидбек, будем эту страничку улучшать. Но на текущий момент это единственный (и самый правильный) путь к тому, чтобы началось обсуждение заявки. Через нас проходит очень большое количество людей и крайне сложно удержать всех в голове, если заявки раскиданы по разным местам типа почты и скайпа. Наш workflow выработан (и активно дорабатывается) как раз, чтобы свести всю работу в одно место.
Так что я ожидал, что отпишется кто-то кто в теме. То, что его вопрос адресован был мне, лично для меня совсем не очевидно.
В таком случае прошу прощения за недопонимание. Нам адресация вопроса показалось очевидной, поэтому мы просто решили подождать ответа.
Саша Гольдштейн отписался и задал уточняющий вопрос по докладу, но ответа мы так и не получили.
Для потенциальных спикеров у нас есть форма call for papers: https://dotnext-piter.ru/callforpapers/ (Ссылка имеется в шапке сайта). После отправки заявки для каждого спикера заводится канал в слеке (где с ним могут пообщаться все члены программного комитета) + тикеты в джире. Программный комитет мониторит тикеты + раз в неделю мы целенаправленно проходимся по всем задачам, что позволяет ни про кого не забыть. Подобный workflow хорошо работает и позволяет избегать непонятных проблем.
В вашей ситуации получилось так, что вы послали письмо сразу на почту (основная часть ПК заявку даже не видела), Саша задал вопрос по заявке, я увидел открытый вопрос и решил подождать ответа, ответа не последовало, про заявку забыли. Мы всюду рекламируем нашу CFP-форму и агитируем засылать идеи докладов именно через неё: это позволяет держать работу с докладчиками под контролем.
Зависит. Прежде всего зависит от потребностей конторы и готовности самим фиксить баги в моно. Rider бежит поверх Mono, бежит нормально. Проблемы есть, на них приходится тратить определённое время, но при желании на этом рантайме можно разрабатывать вполне серьёзные приложения.
Спасибо за дополнение! Рад, что у вас нет проблем со скоростью и интерфейсом, Xamarin действительно очень прокачался за последнее время. Но хотелось бы сказать, что потребности у народа разные: я постоянно общаюсь с Xamarin-разработчиками, отзывы о платформе у всех различные. Очень здорово, что на рынке имеется подобный инструмент, но судя по всему направления для развития всё ещё есть. =)
Никакой лжи тут нет. Я каждый день смотрю на снэпшоты R# и Rider и прекрасно понимаю, почему имеются определённые проблемы со скоростью в VS. Тот же самый код отрабатывает мгновенно в Райдере, что наводит на определённые размышления. Вы можете самостоятельно снять профиль работы студии и Райдера и разобраться что там и как. Никого обмануть я не пытался, а просто озвучивал собственное честное мнение. Могу подписаться под каждым словом.
А мы целенаправленно следим за этим и постоянно проверяем самые разные проекты. Если солюшн маленький, то жить ещё можно. А вот когда у вас сотни проектов и миллионы строк кода, а вы что-нибудь активно рефакторите, то ситуация с памятью становится грустной (в том числе в VS 2017 RC).
Пока что простого путя для дебага нет: если возникли проблемы, то нужно открыть сгенерированный проект и дебажить его. Ну или вызвать проблемный метод в основной программе руками. Хотим в дальнейшем упростить дебаг, но в общем случае вспомогательные проекты всё равно будут генерироваться, собираться и запускаться: без этого не сделать сравнение разных окружений (и много других проблем появится).
Ну так это даже не моя шутка была.
А в целом, доклад был изначально задуман как послеобеденный и полуразвлекательный, чтобы народ немного отдохнул в середине конференции. Увы, никогда не получается сделать так, чтобы все шутки всем понравились. Специально для этого у нас делается одновременно несколько треков, а сетку мы пытаемся сделать таким образом, чтобы каждый нашёл наиболее подходящий для себя доклад (не только по тематике, но и по формату).
Тогда приходите на нашу замечательную конференцию, в своём докладе я буду рассказывать о том, как же решать эту и многие другие проблемы без всякой C++ магии. =)
В целом мы пытаемся добиться ситуации, в которой значимые деградации просто не могут вмёрджиться. Для этого у нас есть performance-тесты, которые динамически подбирают оптимальное количество итераций (в докладе я как раз про это рассказываю). Для пущей уверенности тесты перезапускаются на нескольких машинах, чтобы гарантированно избежать ложноположительных результатов.
Но вы правы в том, что такие тесты не всегда спасают от регрессий. Пожалуй, самая главная проблема в том, что таких тестов не очень много (т.к. они очень долго идут), покрыты только наиболее критичные сценарии. Поэтому есть система мониторинга, которая шлёт в Slack разнообразные нотификации об уже замёрдженных деградациях. Какого-то красивого универсального подхода к таким проблемам нет, мы просто разбираем все проблемы вручную и пытаемся найти наиболее правильное решение. Обычно, оно попадает в одну из следующих категорий:
По сути, починка вмёрдженной performance-регрессии не особо отличается от починки вмёрдженной обычной регрессии по функциональности: либо откатываем, либо фиксим прямо в master-ветке. Насколько мне известно, принципиально других подходов в индустрии пока не появилось. Единственное отличие performance-регрессий в том, что от них чаще можно отмахнуться и сказать “ну и ладно, не так уж и медленно оно работает, у нас и поважнее задачи есть”, но нужно глубокое понимание продукта для того, чтобы определить ситуации, в которых так сказать действительно можно.
Но если очень-очень хочется, то сделать это всё-таки можно. Нужно скопипастить дефолтный конфиг и поменять реализацию
GetColumnProviders(вот тут можно посмотреть что подставляется по дефолту).А чего не хватает?
Работаем в этом направлении, но сомневаюсь, что мы сможем что-то показать раньше середины 2018-го (там очень много сложных технических задач).
Раздел «Содержание доклада на 20-30 пунктов» появился не от хорошей жизни. Раньше в 95% случаев спикеры присылали очень короткое описание (иногда буквально в одно предложение), из которого не особо понятно о чём пойдёт речь в докладе. И практически всегда общение со спикером начиналось со слов «А можете поподробнее расписать о чём доклад?». Поэтому мы добавили такую формулировку в форму. Если пунктов будет меньше 20, то заявку всё равно можно отправить, это лишь рекомендуемый объём (который в большинстве случаев экономит всем время). Спасибо за фидбек, будем эту страничку улучшать. Но на текущий момент это единственный (и самый правильный) путь к тому, чтобы началось обсуждение заявки. Через нас проходит очень большое количество людей и крайне сложно удержать всех в голове, если заявки раскиданы по разным местам типа почты и скайпа. Наш workflow выработан (и активно дорабатывается) как раз, чтобы свести всю работу в одно место.
В таком случае прошу прощения за недопонимание. Нам адресация вопроса показалось очевидной, поэтому мы просто решили подождать ответа.
Саша Гольдштейн отписался и задал уточняющий вопрос по докладу, но ответа мы так и не получили.
Для потенциальных спикеров у нас есть форма call for papers: https://dotnext-piter.ru/callforpapers/ (Ссылка имеется в шапке сайта). После отправки заявки для каждого спикера заводится канал в слеке (где с ним могут пообщаться все члены программного комитета) + тикеты в джире. Программный комитет мониторит тикеты + раз в неделю мы целенаправленно проходимся по всем задачам, что позволяет ни про кого не забыть. Подобный workflow хорошо работает и позволяет избегать непонятных проблем.
В вашей ситуации получилось так, что вы послали письмо сразу на почту (основная часть ПК заявку даже не видела), Саша задал вопрос по заявке, я увидел открытый вопрос и решил подождать ответа, ответа не последовало, про заявку забыли. Мы всюду рекламируем нашу CFP-форму и агитируем засылать идеи докладов именно через неё: это позволяет держать работу с докладчиками под контролем.
Ещё не решили. Сначала нужно дописать продукт, а потом будем думать про лицензирование. =)
Зависит. Прежде всего зависит от потребностей конторы и готовности самим фиксить баги в моно. Rider бежит поверх Mono, бежит нормально. Проблемы есть, на них приходится тратить определённое время, но при желании на этом рантайме можно разрабатывать вполне серьёзные приложения.
Спасибо за дополнение! Рад, что у вас нет проблем со скоростью и интерфейсом, Xamarin действительно очень прокачался за последнее время. Но хотелось бы сказать, что потребности у народа разные: я постоянно общаюсь с Xamarin-разработчиками, отзывы о платформе у всех различные. Очень здорово, что на рынке имеется подобный инструмент, но судя по всему направления для развития всё ещё есть. =)
Да, видел. Кстати говоря, Matt Warren (автор статьи) — один из разработчиков BenchmarkDotNet.
Никакой лжи тут нет. Я каждый день смотрю на снэпшоты R# и Rider и прекрасно понимаю, почему имеются определённые проблемы со скоростью в VS. Тот же самый код отрабатывает мгновенно в Райдере, что наводит на определённые размышления. Вы можете самостоятельно снять профиль работы студии и Райдера и разобраться что там и как. Никого обмануть я не пытался, а просто озвучивал собственное честное мнение. Могу подписаться под каждым словом.
Спасибо, с каждым новым днём стараемся делать Rider всё лучше и лучше. =)
Думаем над этим, но это не очень просто.
Вся логика на фронтэнде (там где мы интегрируемся с IDEA) написана на Kotlin на 100%. Бэкэнд (R#) пишется по понятным причинам на C#.
А мы целенаправленно следим за этим и постоянно проверяем самые разные проекты. Если солюшн маленький, то жить ещё можно. А вот когда у вас сотни проектов и миллионы строк кода, а вы что-нибудь активно рефакторите, то ситуация с памятью становится грустной (в том числе в VS 2017 RC).
Пока что простого путя для дебага нет: если возникли проблемы, то нужно открыть сгенерированный проект и дебажить его. Ну или вызвать проблемный метод в основной программе руками. Хотим в дальнейшем упростить дебаг, но в общем случае вспомогательные проекты всё равно будут генерироваться, собираться и запускаться: без этого не сделать сравнение разных окружений (и много других проблем появится).
Ок, спасибо за конструктивный фидбек. Будем стараться работать над форматом.
Ну так это даже не моя шутка была.
А в целом, доклад был изначально задуман как послеобеденный и полуразвлекательный, чтобы народ немного отдохнул в середине конференции. Увы, никогда не получается сделать так, чтобы все шутки всем понравились. Специально для этого у нас делается одновременно несколько треков, а сетку мы пытаемся сделать таким образом, чтобы каждый нашёл наиболее подходящий для себя доклад (не только по тематике, но и по формату).
А что не так?
Вот пара ссылок на tex.stackexchange, в которых обсуждается ваша проблема:
Так же рекомендую просмотреть инструкцию по работе с библиографией для шаблона, там много полезной информации:
Если не сможете справиться с проблемой, то лучше всего написать о ней в наш чат:
Тогда приходите на нашу замечательную конференцию, в своём докладе я буду рассказывать о том, как же решать эту и многие другие проблемы без всякой C++ магии. =)