Про индекс согласен, не заметил уникальный ключ. В остальном, Вы тестируете производительность трёх разных способов выполнения этого запроса. Это, разумеется, не то же самое, что производительность базы данных. Но условия для выполнения тестов, во-первых, не приближены к реальным, а, во-вторых, не симметричные. Я всего лишь вежливо предложил этот тест адаптировать и посмотреть, что получится. Не понимаю, откуда столько агрессии. Готов дискутировать по деталям, но только при условии уважительной дискуссии.
Возможно я что-то упускаю, но есть подозрение, что тест, который Вы опубликовали, не вполне представителен. Как я понимаю, Вы выполняете одни и те же запросы на одной базе данных. И по "странному" стечению обстоятельств первый тест медленнее второго, а второй медленнее третьего. Это может говорить о том, что база данных "прогрелась" и одни и те же запросы достаются из кэша. Кроме того, объёмы данных совсем минимальные, чтобы вообще судить о производительности. Кроме того, не вижу у вас индекса. Кроме того, не вижу параллельного выполнения запросов. Рекомендую для большей наглядности тестов, добавить в базу 10 миллионов записей, выполнять тесты в 100 потоков и каждый тест выполнять на новом инстансе базы данных. Тогда возможно получите результаты более близкие к тем, о которых Вам говорили.
Я правильно понял, что для анализа запроса он отправляется на какой-то сторонний сервер, ещё и где-то в России? Тогда сразу масса вопросов.
Как можно сделать анализ запроса не имея под рукой схему базы данных?
Как можно сделать анализ запроса не имея под рукой самих данных (ведь использование индексов сильно зависит от количества строк в таблице, например иногда выгоднее делать Full Scan)?
Сливается ли это всё на российский сервер? А если нет, точность таких анализов и сопутствующих "советов по оптимизации" вероятно мизерная.
В идее есть стандартный встроенный плагин для построения плана запроса (он даже на ваших скриншотах виден). Насколько есть смысл рисковать словом данных непонятно куда вместо использования этого плагина?
Emacs, разумеется, не является IDE. Но Вы работаете не в голом Emacs, а в полноценной среде (Emacs + плагины). Вы удивитесь, но эта среда и есть IDE, на что намекают приведённые выше цитаты. То, что определённые плагины загружаются на определённые файлы, является особенностью любой другой IDE. Так что не понимаю, в чём предмет спора тут. Вы набираете руками команды в консоли или используете то, что предоставляет Ваша не-IDE?
То, что Вы описали, справедливо для любой другой IDE: в зависимости от типа файла работают те или иные плагины. Отличие лишь в наборе плагинов и возможно в порядке их загрузки. А принципиально в чём отличие? Или Вы утверждаете, что то, в чём Вы работаете, это обычный консольный текстовый редактор, как описано в статье? Вы все команды в командной строке набираете или используете готовые short-cut-ы из того, что Вы не хотите называть IDE?
Прямая цитата из текущей статьи: "Если вы относитесь к тому типу программистов, которые наслаждаются жизнью в терминале и могут легко обходиться без графического интерфейса, то Vim — отличный выбор для редактирования кода."
Тут выяснилась интересная подробность. В соседней ветке товарищ, который защищает Vim, сам работает в IDE. Поэтому хотелось бы заранее понять, о чём мы говорим с Вами. Вот тут есть такая статья про NeoVim https://habr.com/ru/companies/avito/articles/682962/ Цитаты из этой статьи
В готовых конфигурациях уже есть всё необходимое, чтобы пользоваться NeoVim как обычной IDE.
Плагины: превращаем редактор кода в полноценную IDE
Так вот что у Вас: консольный редактор, как описано в комментируемой статье, или всё-таки полноценная IDE?
Так статья о чём? Автор говорит о консольном текстовом редакторе. Я отметил в изначальном комментарии, что использовать такое в современной работе невозможно, нужно использовать IDE. Вы сами используете IDE, а не то, что описывается в статье. Не понимаю, с чем Вы конкретно не согласны.
Переименование класса / метода с заменой по всему проекту
Вынесение части кода в отдельный метод
Добавление параметра в метод с постановкой значения по умолчанию по всему проекту
Поменять параметры метода местами
"Провалиться" в реализацию метода из места, где этот метод используется через интерфейс
Подсветить ошибки в коде без запуска компилятора
Подключить к проекту систему сборки и иметь возможность использовать публичные библиотеки
Поиск класса среди всех подключённых библиотек по названию
Предложить варианты определения значения переменной по типу
Предложить класс / функцию по двум трём буквам названия (не обязательно идущих подряд)
Посмотреть всю иерархию класса
Запустить тесты (все тесты в проекте, все тесты в конкретном классе, один конкретный тест)
Дебаг: узнать значение переменной в нужном месте, выполнить вычисления в нужном месте
Spring: автоматически предложить возможные настройки в конфигурации, перейти из файла конфигурации в проперти класс, перейти к определению бина из места его использования
Вот, с ходу столько уже придумал. Всё это делается одной комбинацией клавиш или парой щелчков мышью. А как это делаете Вы?
Думаю Вы согласны, что у Вас особый случай, что Вам приходится работать сразу в нескольких платформах одновременно. Вероятно, Вам действительно проще иметь текстовые редактор для всех платформ.
Для остальных, кто специализируется на одной, мой вывод остаётся верен.
Кроме того, позвольте уточнить, Вы под эти все платформы именно ведёте полноценную разработку или просто собираете/вкладываете?
Что касается портянки проблем. Опишите хотя бы парочку, интересно посмотреть, актуальны ли эти проблемы в моём случае.
Я не знаю, какая у Вас платформа (язык программирования, система сборки, фреймворки), но для своей (Java/Kotlin, Maven/Gradle, Spring Boot) могу накидать с десяток функций, которые в текстовом редакторе просто невозможно сделать эффективно. Вы, конечно можете научиться быстро набирать типовые скрипты, но это всё равно не будет быстрее, чем стандартная готовая функция внутри IDE, которая делает тоже самое сразу без набора скрипта одной комбинацией клавиш (или мышью).
Так он и выучить не мог. Выучить подразумевает, что в какой-то момент он их реально знал. Что просто невозможно, учитывая, что у него на каждый язык было меньше года опыта.
Все, что написано в скетче Ардуино это обычный C++ с подключёнными заголовками, которые обозначают функции микро контроллера. Ардуино просто вызывает эти функции в нужном порядке и умеет реагировать на нужные функции нужным способом. Никакого уникального языка в этом смысле нет. Поправьте, если что-то изменилось за последнее время.
Вероятно для hello world проектов с двумя тремя файлами текстового редактора достаточно, но если у вас сложный проект с зависимостями, библиотеками, системами сборки вроде Maven и Gradle, сложными фреймворками и т.д., просто невозможно представить эффективную работу без нормального IDE.
Vim был хорош в своё время, но как можно спорить, что сейчас, когда выбор IDE так велик, можно обойтись текстовым редактором для сложного проекта?
В целом общее замечание, как и к первой статье, очень много лишнеготекста. Примеров побольше, но в тексте они теряются.
По содержанию, было интересно посмотреть на "Сопротивляемость рефакторингу". К сожалению мои ожидания не оправдались. Я думаю, что это свойство можно было раскрыть гораздо шире, чем тривиальное утверждение "если меняется только тело метода, то тесты переписывать не нужно ".
То, что Вы назвали "Зависимость от интерфейса", имеет устоявшееся в "науке" наименование "inversion of control". Для солидности неплохо было бы привести ссылку на статью об этом паттерне.
Компоненты, которые Вы назвали "Humble object" можно и даже нужно тестировать. Представьте, что у вас в репозитории написан гигантский SQL запрос с join и подзапросами. Для тестирования таких объектов существуют специальные библиотеки. В Java это testcontainers и mockserver. Наверняка что-то существует и для Вашей платформы (это вроде бы Nodejs)
Было бы неплохо хотя бы одно предложение насчёт языка программирования: какой язык используется в примерах и валидно ли всё, что Вы написали выше, для других языков тоже.
Интересно посмотреть, что Вы имеете в виду под "сопротивляемость рефакторингу". Надеюсь в следующей серии будет меньше текста и больше примеров на эту тему.
Про индекс согласен, не заметил уникальный ключ. В остальном, Вы тестируете производительность трёх разных способов выполнения этого запроса. Это, разумеется, не то же самое, что производительность базы данных.
Но условия для выполнения тестов, во-первых, не приближены к реальным, а, во-вторых, не симметричные. Я всего лишь вежливо предложил этот тест адаптировать и посмотреть, что получится. Не понимаю, откуда столько агрессии.
Готов дискутировать по деталям, но только при условии уважительной дискуссии.
Возможно я что-то упускаю, но есть подозрение, что тест, который Вы опубликовали, не вполне представителен.
Как я понимаю, Вы выполняете одни и те же запросы на одной базе данных. И по "странному" стечению обстоятельств первый тест медленнее второго, а второй медленнее третьего. Это может говорить о том, что база данных "прогрелась" и одни и те же запросы достаются из кэша.
Кроме того, объёмы данных совсем минимальные, чтобы вообще судить о производительности.
Кроме того, не вижу у вас индекса.
Кроме того, не вижу параллельного выполнения запросов.
Рекомендую для большей наглядности тестов, добавить в базу 10 миллионов записей, выполнять тесты в 100 потоков и каждый тест выполнять на новом инстансе базы данных.
Тогда возможно получите результаты более близкие к тем, о которых Вам говорили.
Я правильно понял, что для анализа запроса он отправляется на какой-то сторонний сервер, ещё и где-то в России? Тогда сразу масса вопросов.
Как можно сделать анализ запроса не имея под рукой схему базы данных?
Как можно сделать анализ запроса не имея под рукой самих данных (ведь использование индексов сильно зависит от количества строк в таблице, например иногда выгоднее делать Full Scan)?
Сливается ли это всё на российский сервер?
А если нет, точность таких анализов и сопутствующих "советов по оптимизации" вероятно мизерная.
В идее есть стандартный встроенный плагин для построения плана запроса (он даже на ваших скриншотах виден). Насколько есть смысл рисковать словом данных непонятно куда вместо использования этого плагина?
Emacs, разумеется, не является IDE. Но Вы работаете не в голом Emacs, а в полноценной среде (Emacs + плагины). Вы удивитесь, но эта среда и есть IDE, на что намекают приведённые выше цитаты.
То, что определённые плагины загружаются на определённые файлы, является особенностью любой другой IDE.
Так что не понимаю, в чём предмет спора тут. Вы набираете руками команды в консоли или используете то, что предоставляет Ваша не-IDE?
То, что Вы описали, справедливо для любой другой IDE: в зависимости от типа файла работают те или иные плагины. Отличие лишь в наборе плагинов и возможно в порядке их загрузки. А принципиально в чём отличие?
Или Вы утверждаете, что то, в чём Вы работаете, это обычный консольный текстовый редактор, как описано в статье? Вы все команды в командной строке набираете или используете готовые short-cut-ы из того, что Вы не хотите называть IDE?
Прямая цитата из текущей статьи:
"Если вы относитесь к тому типу программистов, которые наслаждаются жизнью в терминале и могут легко обходиться без графического интерфейса, то Vim — отличный выбор для редактирования кода."
Тут выяснилась интересная подробность.
В соседней ветке товарищ, который защищает Vim, сам работает в IDE.
Поэтому хотелось бы заранее понять, о чём мы говорим с Вами.
Вот тут есть такая статья про NeoVim
https://habr.com/ru/companies/avito/articles/682962/
Цитаты из этой статьи
В готовых конфигурациях уже есть всё необходимое, чтобы пользоваться NeoVim как обычной IDE.
Плагины: превращаем редактор кода в полноценную IDE
Так вот что у Вас: консольный редактор, как описано в комментируемой статье, или всё-таки полноценная IDE?
Так статья о чём? Автор говорит о консольном текстовом редакторе. Я отметил в изначальном комментарии, что использовать такое в современной работе невозможно, нужно использовать IDE. Вы сами используете IDE, а не то, что описывается в статье. Не понимаю, с чем Вы конкретно не согласны.
Ну ок, цитата из второй вашей ссылки:
"Client for Language Server Protocol (v3.14). lsp-mode aims to provide IDE-like experience"
То есть у вас таки IDE, а не голый консольный текстовый редактор.
Вы случайно не это используете?
https://github.com/emacs-lsp/lsp-java
Там прямо таки написано: "Emacs Java IDE". То есть у вас таки IDE, хоть и сильно обрезанная.
Переименование класса / метода с заменой по всему проекту
Вынесение части кода в отдельный метод
Добавление параметра в метод с постановкой значения по умолчанию по всему проекту
Поменять параметры метода местами
"Провалиться" в реализацию метода из места, где этот метод используется через интерфейс
Подсветить ошибки в коде без запуска компилятора
Подключить к проекту систему сборки и иметь возможность использовать публичные библиотеки
Поиск класса среди всех подключённых библиотек по названию
Предложить варианты определения значения переменной по типу
Предложить класс / функцию по двум трём буквам названия (не обязательно идущих подряд)
Посмотреть всю иерархию класса
Запустить тесты (все тесты в проекте, все тесты в конкретном классе, один конкретный тест)
Дебаг: узнать значение переменной в нужном месте, выполнить вычисления в нужном месте
Spring: автоматически предложить возможные настройки в конфигурации, перейти из файла конфигурации в проперти класс, перейти к определению бина из места его использования
Вот, с ходу столько уже придумал. Всё это делается одной комбинацией клавиш или парой щелчков мышью. А как это делаете Вы?
Думаю Вы согласны, что у Вас особый случай, что Вам приходится работать сразу в нескольких платформах одновременно. Вероятно, Вам действительно проще иметь текстовые редактор для всех платформ.
Для остальных, кто специализируется на одной, мой вывод остаётся верен.
Кроме того, позвольте уточнить, Вы под эти все платформы именно ведёте полноценную разработку или просто собираете/вкладываете?
Что касается портянки проблем. Опишите хотя бы парочку, интересно посмотреть, актуальны ли эти проблемы в моём случае.
Я не знаю, какая у Вас платформа (язык программирования, система сборки, фреймворки), но для своей (Java/Kotlin, Maven/Gradle, Spring Boot) могу накидать с десяток функций, которые в текстовом редакторе просто невозможно сделать эффективно. Вы, конечно можете научиться быстро набирать типовые скрипты, но это всё равно не будет быстрее, чем стандартная готовая функция внутри IDE, которая делает тоже самое сразу без набора скрипта одной комбинацией клавиш (или мышью).
Так он и выучить не мог. Выучить подразумевает, что в какой-то момент он их реально знал. Что просто невозможно, учитывая, что у него на каждый язык было меньше года опыта.
Все, что написано в скетче Ардуино это обычный C++ с подключёнными заголовками, которые обозначают функции микро контроллера. Ардуино просто вызывает эти функции в нужном порядке и умеет реагировать на нужные функции нужным способом. Никакого уникального языка в этом смысле нет. Поправьте, если что-то изменилось за последнее время.
Так ведь автор статьи сам утверждает, что "знает" 30 языков.
Даже до того, как увидел весь список, было понятно, что в реальности он не знает ни один из этих языков. Он просто к ним прикасался.
Утверждать, что знаешь какой-то язык можно лишь после 5-6 лет опыта реальной работы.
Но когда увидел в списке Arduino (это вообще не язык, а технология для микроконтрллеров), а также 3 варианта SQL, всё стало ясно.
Вероятно для hello world проектов с двумя тремя файлами текстового редактора достаточно, но если у вас сложный проект с зависимостями, библиотеками, системами сборки вроде Maven и Gradle, сложными фреймворками и т.д., просто невозможно представить эффективную работу без нормального IDE.
Vim был хорош в своё время, но как можно спорить, что сейчас, когда выбор IDE так велик, можно обойтись текстовым редактором для сложного проекта?
Наконец дождался второй части :)
В целом общее замечание, как и к первой статье, очень много лишнеготекста. Примеров побольше, но в тексте они теряются.
По содержанию, было интересно посмотреть на "Сопротивляемость рефакторингу". К сожалению мои ожидания не оправдались. Я думаю, что это свойство можно было раскрыть гораздо шире, чем тривиальное утверждение "если меняется только тело метода, то тесты переписывать не нужно ".
Позвольте несколько замечаний:
То, что Вы назвали "Зависимость от интерфейса", имеет устоявшееся в "науке" наименование "inversion of control". Для солидности неплохо было бы привести ссылку на статью об этом паттерне.
Компоненты, которые Вы назвали "Humble object" можно и даже нужно тестировать. Представьте, что у вас в репозитории написан гигантский SQL запрос с join и подзапросами. Для тестирования таких объектов существуют специальные библиотеки. В Java это testcontainers и mockserver. Наверняка что-то существует и для Вашей платформы (это вроде бы Nodejs)
Было бы неплохо хотя бы одно предложение насчёт языка программирования: какой язык используется в примерах и валидно ли всё, что Вы написали выше, для других языков тоже.
Интересно посмотреть, что Вы имеете в виду под "сопротивляемость рефакторингу". Надеюсь в следующей серии будет меньше текста и больше примеров на эту тему.