Мне кажется нельзя оставлять на протезах отверстия любого вида, т.к. ими можно за что-то зацепиться, или повиснуть. Например, животное падает с тумбы, цепляется протезом за ручку и повисает, или ломает конечность.
С одной стороны, это чисто политический вопрос — хочет ли компания влиять на политику. А она может — исходя из своего размера. Можно сказать что «мы — бизнес», и должны руководствоваться доходом, а не политическими убеждениями.
Но с другой стороны, если смотреть чуть дальше — тот же бизнес-подход даст совсем другой ответ.
В-т 1. Вот вышли в Китай, вот прогнулись под требования. Но заодно, потеряли «фишку» «мы за права человека» и «don't be evil». С одной стороны, сейчас заработали больше денег. С другой — через лет пять, Китай запустит аналоги каждого гугл-сервиса и гугл окажется там же где сейчас, только уже с клеймом «за деньги — продадим вас».
В-т 2. Учитывая текущий тренд на права человека, свободу слова, и вот это вот всё, может оказаться очень выгодно форсить фишку «don't be evil». И тогда — через те же пять лет, в «не Китае», Гугл — это оплот света, а не просто ещё одна корпорация.
Вот всё и сводится к выгоде сиюминутной против долгосрочной.
Хабр-Чат. В любой группе прогеров в любой фирме, есть некий общий чатик, где можно похоливарить, или задать нубский вопрос, скинуть новость. Чат наподобие группы телеграма или вайбера, но в браузере.
В любой момент можно зайти и подключиться к обсуждению/срачу. Должны быть, конечно, тематические подчатики. И желательно мочь дискуссию продолжать в новом подчате, а не засирать то место, где она началась (как в слаке). Зачем? Чтобы похоливарить, чтобы поубивать время, чтобы задать нубский или риторический вопрос, поделиться новостью, или мемасиком. Всё то, что слишком холиварно, или слишком просто для форума, или тостера.
Не запускал, конечно. Грамматика не покрыта же ещё.
Кстати, интересно было бы по ANTLR посмотреть. Там наткнулся что вот такой код SimpleClass().foo<String>("") не парсится.
Я нигде не говорил что это размер чистого парсера. Написано: "… посмотреть на размер джара со всеми зависимостями".
Кроме того, я везде привожу ссылки на код, который тестируется. Как тут можно что-то не так понять?
И ещё раз. Тем не менее. Я упомянул. Про чистый размер парсеров.
Это же относительные результаты, понятно что во всех случаях что-то дополнительное есть. Но если таки заморочиться, то JavaCC выйдет ещё красивее — 66КБ против ANTLR 680КБ. О чём я, кстати, упомянул.
Я не говорю что прямо так важен, но обращать внимание на него стоит, ведь даже на десктопе — это не просто 30МБ на терабайтном винте, это 30МБ кода.
(Плюс абзац из публикации, не буду повторяться).
Размер я мерял со всеми зависимостями.
kotlinAntlr-0.1-SNAPSHOT-jar-with-dependencies — 15МБ, основной вес в зависимости com.ibm.icu
Про SQL — это несколько пренебрежительно, не находите?
1. Первое требование — удобство разработчика и пользователя.
2. Тут я меряю конкретно то что мне нужно.
3. Компактнее не выйдет. При сохранении функционала, конечно.
4. Вы невнимательно читали.
5. Мне не нужна цифра «время исполнения в Х итерациях после У разогревов». Мне нужно минимальное время к первому, десятому, сотому, тысячному вызову.
6. На 1000й вызов JetBrains моя цифра выходит чуть больше чем в JMH, на 50000й — меньше. Как я указывал, при таком агрессивном JIT, меня интересует именно динамика. А конкретное число — вообще имеет мало смысла. Я бы ещё понял претензию об однообразии данных!
Ну и мелочи. Мои тесты проходят за пару секунд, а не за минуту, ещё и форматируется это всё, чтобы в любой момент можно было повторить замеры и скопипастить в нужный отчёт.
Думаю, в 21м веке каждый волен использовать любой удобный инструмент, если понимает что он делает.
В №1 вы говорите об изменившихся цифрах. Но вы замеряете ДРУГУЮ имплементацию, а пишите что только заменили методику сбора.
Нужно быть внимательнее в построении предложений.
Спасибо за ссылку, обязательно почитаю! Интересно будет узнать что в ANTLR можно сделать лучше. Однако, первой же в голову приходит мысль — а ведь в JavaCC я писал «в лоб», без каких либо ухищрений. И размер fat jar со временем первого старта — вряд ли изменятся.
(Кстати, грамматика на ANTLR — не моя)
Да, можно не тащить. Но и о разработчике я бы не стал забывать тоже, он ведь тот, кто чаще чем кто либо другой будет запускать проект. Ну и habr.com/post/433000/#comment_19503612
Конечно, выбор платформы это тема для совсем другой статьи, но лично моё мнение — Java, как и C#, позволяют разработчику быть гораздо эффективнее, чем… эм, многое другое.
1. JMH интересен, конечно, и иногда цифры даже совпадают на стотысячный вызов. А иногда мой стотысячный выходит быстрее. В общем, это совсем другая тема, и для статьи, возможно, надёжнее было бы выложить именно его результаты. Но в любом случае, это всего лишь тысячный вызов, а, как я написал — меня интересовала именно динамика времени.
2. Отличное замечание! Действительно, кешируя именно это значение можно ускорить JetBrains в два с половиной раза (в данных конкретных условиях). Kotlin IntelliJ parser (without analyzer, cached project)
first call elapsed : 1272.145ms
min time in next 10 calls: 5.031ms
min time in next 100 calls: 1.486ms
min time in next 1000 calls: 0.38ms
Whole time for 1111 calls: 1.518542s
3. Файл закроется в finalize, но вы правы, лучше делать это явно. Тем более раз он начал использоваться более чем для чтения пары файлов.
4. А вот почему в вашем замере ускорение в четыре раза — это действительно интересно. У вас используется CoreLocalFileSystem и именно он даёт буст. С первых же вызовов 0.4мс вместо 5. Уж не кешируется ли там результат парсинга?
Kotlin IntelliJ parser (without analyzer, CoreLocalFileSystem)
first call elapsed : 1233.702ms
min time in next 10 calls: 0.418ms
min time in next 100 calls: 0.127ms
min time in next 1000 calls: 0.041ms
Whole time for 1111 calls: 0.11175224s
Но с другой стороны, если смотреть чуть дальше — тот же бизнес-подход даст совсем другой ответ.
В-т 1. Вот вышли в Китай, вот прогнулись под требования. Но заодно, потеряли «фишку» «мы за права человека» и «don't be evil». С одной стороны, сейчас заработали больше денег. С другой — через лет пять, Китай запустит аналоги каждого гугл-сервиса и гугл окажется там же где сейчас, только уже с клеймом «за деньги — продадим вас».
В-т 2. Учитывая текущий тренд на права человека, свободу слова, и вот это вот всё, может оказаться очень выгодно форсить фишку «don't be evil». И тогда — через те же пять лет, в «не Китае», Гугл — это оплот света, а не просто ещё одна корпорация.
Вот всё и сводится к выгоде сиюминутной против долгосрочной.
В любой момент можно зайти и подключиться к обсуждению/срачу. Должны быть, конечно, тематические подчатики. И желательно мочь дискуссию продолжать в новом подчате, а не засирать то место, где она началась (как в слаке). Зачем? Чтобы похоливарить, чтобы поубивать время, чтобы задать нубский или риторический вопрос, поделиться новостью, или мемасиком. Всё то, что слишком холиварно, или слишком просто для форума, или тостера.
Кстати, интересно было бы по ANTLR посмотреть. Там наткнулся что вот такой код
SimpleClass().foo<String>("")не парсится.Кроме того, я везде привожу ссылки на код, который тестируется. Как тут можно что-то не так понять?
И ещё раз. Тем не менее. Я упомянул. Про чистый размер парсеров.
(Плюс абзац из публикации, не буду повторяться).
Размер я мерял со всеми зависимостями.
kotlinAntlr-0.1-SNAPSHOT-jar-with-dependencies — 15МБ, основной вес в зависимости com.ibm.icu
1. Первое требование — удобство разработчика и пользователя.
2. Тут я меряю конкретно то что мне нужно.
3. Компактнее не выйдет. При сохранении функционала, конечно.
4. Вы невнимательно читали.
5. Мне не нужна цифра «время исполнения в Х итерациях после У разогревов». Мне нужно минимальное время к первому, десятому, сотому, тысячному вызову.
6. На 1000й вызов JetBrains моя цифра выходит чуть больше чем в JMH, на 50000й — меньше. Как я указывал, при таком агрессивном JIT, меня интересует именно динамика. А конкретное число — вообще имеет мало смысла. Я бы ещё понял претензию об однообразии данных!
Ну и мелочи. Мои тесты проходят за пару секунд, а не за минуту, ещё и форматируется это всё, чтобы в любой момент можно было повторить замеры и скопипастить в нужный отчёт.
Думаю, в 21м веке каждый волен использовать любой удобный инструмент, если понимает что он делает.
Нужно быть внимательнее в построении предложений.
(Кстати, грамматика на ANTLR — не моя)
2. Отличное замечание! Действительно, кешируя именно это значение можно ускорить JetBrains в два с половиной раза (в данных конкретных условиях).
Kotlin IntelliJ parser (without analyzer, cached project)
first call elapsed : 1272.145ms
min time in next 10 calls: 5.031ms
min time in next 100 calls: 1.486ms
min time in next 1000 calls: 0.38ms
Whole time for 1111 calls: 1.518542s
3. Файл закроется в finalize, но вы правы, лучше делать это явно. Тем более раз он начал использоваться более чем для чтения пары файлов.
4. А вот почему в вашем замере ускорение в четыре раза — это действительно интересно. У вас используется CoreLocalFileSystem и именно он даёт буст. С первых же вызовов 0.4мс вместо 5. Уж не кешируется ли там результат парсинга?
Kotlin IntelliJ parser (without analyzer, CoreLocalFileSystem)
first call elapsed : 1233.702ms
min time in next 10 calls: 0.418ms
min time in next 100 calls: 0.127ms
min time in next 1000 calls: 0.041ms
Whole time for 1111 calls: 0.11175224s