делать миграции?)
Руками
Я как выяснил. В крупных и сложных проектах orm это плохо, потому что делает лишние телодвижения (менее производительнее). А так 50\50 люди делятся, кто за то что плохо или нет. Могу ошибаться в каких-то моментах, так как только перехожу после js)
> менее производительнее Те, кто это говорят, даже не знают, что такое профайлинг и не могут элементарно измерить время выполнения того или иного участка кода. Я не использую ORM, но совсем по другим причинам
> Те, кто это говорят, даже не знают, что такое профайлинг и не могут элементарно измерить время выполнения того или иного участка кода причем здесь профайлинг? ОРМ действительно очень неплохой оверхед привносит
Ещё один. Сколько конкретно?
А можно узнать по каким именно причинам?
1. Не использую автомиграции, которые есть во многих ORM 2. Не считаю логичным описывать модели, соответствующие таблицам в БД, потому что результаты выборки далеко не всегда совпадают с полями таблиц. Мне нравится делать плоские структуры под результаты конкретных запросов. 3. Люблю очевидность и предсказуемость 4. Люблю относительно чётко видеть запрос, который пойдёт в БД, а также их количество 5. Не нравится думать над тем, "а как же мне в ORM построить вот такой вот запрос"
2093нс на простом селекте, 4167нс на более сложном
и я даже не уверен, что это полный цикл селекта забенчмаркан. Запустил бенчмарки в самом горме, коих всего 2 (лол)
Это ж ни о чём. Сетевые издержки на сам запрос к БД это всё сведут в ноль
если для тебя 2-4к нс ни о чем, то у меня плохие новости
Сколько по времени у тебя выполняется любой запрос к БД с учётом сети? Хоть SELECT 1
без понятия. У меня нет поднятых бд
А в этом вся суть. Потому что это значение будет многократно больше того, что ты указал. Настолько больше, что разницей между 2к нс и 4к нс можно пренебречь - это ничтожно малое значение в пределах погрешности. И если принимается решение, юзать ORM или нет, то точно не это должно быть определяющим фактором.
а что за проект такой?
зато что я знаю наверняка, оправдывают медленный код сетевыми издержками только дилетанты
экономят на спичках дилетанты и предварительная оптимизация - тоже из их арсенала
если это ничтожно малое значение в пределах погрешности, то у меня плохие новости
"слышу звон, не слышу откуда". Увы, в ответе тебе не удалось использовать "дилетант" в правильном контексте:) расскажешь мне, что такое предварительная оптимизация?
1 секунда - это много или мало? Мало. А если речь идёт о времени поездки из Санкт-Петербурга в Москву?
о, легко. это когда ты люди начинают оптимизировтаь скорость кода ДО того, как узнают требования по времени исполнения
то есть, мы можем пилить лютый говнокод, выкидывая из головы понятие эффективности?
Зависит от того, что считать эффективностью. Если ORM позволяет повысить эффективность разработки, прибавляя 2к нс ко времени ответа эндпоинта, то не вижу никаких проблем использовать удобный инструмент.
вот и я не вижу. Только изначальный разговор был о том, что эта штука далеко не бесплатная
что значит понятие эффективности? Если ты ускорил свою программу на 4мкс, о чем тебя никто не просил, но потратил на это в два раза больше времени, ты не эффективен. Если твой код работает секунду, а может работать минуту, но его в три раза сложнее читать, ты написал неэффективный код
гдеб найти такую орм? обычно всё скатывается в борьбу с нею и попытки прохачить для получения желаемого
а, ну и при более сложных запросах, мы не отделываемся 2к нс
Эта разница настолько ничтожная, что можно считать, что бесплатная. Какое у тебя время ответа эндпоинтов в сервисе?
https://medium.com/@rocketlaunchr.cloud/how-to-benchmark-dbq-vs-sqlx-vs-gorm-e814caacecb5
Если твоим ресурсои будут пользоваться 1000 человек, а ты заморачиваешься как на лям это и есть предварительная оптимизация. Когда ты пишешь специфические алгоритмы что бы сэкономить несколько байт, это тоже предварительная оптимизация.
Более сложные запросы и в БД будут выполняться обычно более долго
Так и есть. Я насчёт ORM уже выше высказался по пунктам https://t.me/gogolang/842686
> Если твой код работает секунду, а может работать минуту, но его в три раза сложнее читать, ты написал неэффективный код понял. Можешь не продолжать
орм их обрабатывать будет тоже дольше. И тут горм дает неплохой такой оверхед
Сколько по времени отвечает любой эндпоинт твоего сервиса, лазающий в БД? Ты сам сказал "Как можно использовать "много" или "мало" вне сравнения с чем-либо?"
Скорее эффективный но не поддерживаемый
нисколько. Я пишу вебфреймворк. И мне хватает того, что запрос в среднем полносью обрабатывается в 600нс
Если ты с БД не работаешь, то о чём речь вообще? О том, сколько выполняется участок кода в вакууме?
Он же не решает задачу, значит неэффективен:)
Самый быстрый раздатчик хелловорлда в мире:)
Неуловимый Джо какой-то
по крайней мере, я знаю толк в базовых оптимизациях. Я уже продвинутый гофер
Обсуждают сегодня