Поэтому я немного не согласен со статьёй, надо смотреть не бенчмарки от go, а конкретный машинный код на выходе и его уже сравнивать, делать какие-то выводы.
Я просто хотел сказать, что передача по указателю не всегда быстрее передачи значения. Почему-то я постоянно слышу, что это так, хотя мои бенчмарки мне показывают обратную картину.
Если говорить о hot path, то да, его нужно тщательно оптимизировать уже на конкретных кейсах. Но в большинстве случаев при написании кода существенной разницы между передачей по указателю или передачей по значению не будет - это я и хотел доказать, и тем самым призвать читателей использовать то, что больше подходит по смыслу. Например, указатели могут быть nil, и работать с ними тяжелее из-за одного дополнительного возможного значения.
Просто я регулярно слышу "надо передавать большие структуры по указателю, потому что так быстрее". И действительно без бенчмарков не всегда понятно, что быстрее: скопировать всю структуру в стеке или выделить её в куче и передавать указатель.
В статье не производится сравнение "выделять в куче или не выделять", а сравнивается "выделять в куче или копировать потенциально большую структуру каждый раз". Просто регулярно встречаю людей, которые переоценивают время копирования данных и считают это медленной операцией. А потом оправдывают этим использование указателей везде и всегда.
Цель этих бенчмарков не показать, что выделять в куче медленно - как вы верно заметили, это всем было понятно. Цель - показать, что копирование быстрое и в большинстве случаев быстрее, чем передавать указатели. Это инвалидирует один из аргументов сторонников везде передавать и возвращать указатели.
К сожалению, большая часть статьи получилась о бенчмарках, т. к. только производительность можно сравнить по численным характеристикам. Но я также привел аргументы про читаемость и семантические различия передачи значения и указателя.
Возможно, вам стоит посмотреть другие варианты, походить на собесы и сменить работу. Я сам устроился с полутора годами опыта на работу за 250к (go), при этом опыта фриланса у меня не было. Коллеги работают за примерно те же ±200к, у них тоже опыта полтора-два года. Разумеется, это зависит от стека и города, но я уверен, что можно получать больше 100к за то, чем вы занимаетесь.
У меня есть знакомые, которые тоже работают в небольших региональных компаниях за маленькие деньги, хотя могли бы сходить на собесы в компании побольше и с офисами в Москве/Питере и получать заметно больше денег.
Также если вы не меняете работу, то ваша зп может отстать от рыночной - я при каждом переходе получал сильно больше денег (а после первой работы зп выросла вообще в 2.5 раз).
через сколько минут статья утонет в минусах? И выберется ли она из песочницы вообще?
Честно говоря, я бы почитал. Пишите!
А 250к имеют далеко не все сеньоры с 8+ годами опыта. Вам бы детские сказки писать, были бы сплошь бестселлеры.
Ну зачем так грубо. Я ещё даже не сеньор, а зп уже такая. И получал оферы на сильно больше.
Я не говорю, что все компании предлагают много денег, но я не могу согласиться, что все компании предлагают мало. Я сам видел вакансии, собеседовался и получал оферы от разных компаний, и зп в них отличалась очень сильно - мне предлагали и 100к в мелкой компании (при том, что у меня уже были оферы на 180к+), мне предлагали пообщаться о вакансии сеньора Go c 3-5 годами опыта с зп как раз где-то 200-300к или ниже (не помню) в каком-то регионе.
В целом я очень сильно удивляюсь, когда на собесе прошу казалось бы слишком большую зп, а мне согласуют офер на неё. Я считаю, надо ходить и пытаться проверять, где находится тот самый "потолок", выше которого тебе денег не дадут.
А можете подсказать, что вы имеете в виду под объяснением причин проблем? Я вроде постарался везде описать, что и почему происходит, не вдаваясь в подробности и не рассказывая то, что Go разработчики уже наверняка знают. Считаете, что стоило побольше углубиться или что-то иное?
Про профи не соглашусь - все проблемы и примеры взяты из реального опыта, где разработчики среднего уровня и выше писали примерно такой код, при этом не задумываясь "а что если контекст отменится прямо тут?" и "если я использую каналы тут, к каким проблемам это приведет?". Я бы назвал их профи, но некоторые просто не задумывались о таких потенциальных проблемах, а уж тесты на такое писать вообще не каждый любит. А уж писать тесты на случаи кроме happy path - в моем опыте совсем редкость.
Интересная ссылка, спасибо. Но там комментаторы как раз и указывают на то, что намного вероятнее проблема в коде приложения, чем в самом механизме генерации UUID или коллизиях.
Примеры:
It could be that in your actual code, the UUIDs are getting mixed up at a later stage, e.g. due to a race condition somewhere in a higher-level layer.
But, say you generated a set of random numbers with virtual machine A. Then took a snapshot of A. Then sometime later, stopped A, resumed from the snap shot, and resumed generating random numbers
Instead, look for places where a UUID stored by one server could be clobbering one stored by another. Why does this only happen between 2 servers out of 50? That has something to do with the details of your environment and system that haven't been shared.
As stated above, the chances of a legit collision are impossibly small. A more likely possibly is if the values are ever transferred between objects in an improper way. For languages like Java that behave as pass by reference...
Можете поделиться своими историями про коллизии?
Upd 1: вижу ниже подобное обсуждение, мой вопрос неактуален
Декомпозиция обозвана деконструктором, т. к. деконструирует, "разбирает" значение в несколько переменных. Я использовал слово "деконструктор", т. к. по моему мнению так проще понять, что мы говорим о методе Deconstruct(...). Ну и в документации это тоже называют деконструктором.
Деконструктор — это же не то же самое, что и деструктор, и вовсе не антоним конструктора. Тут деконструктор позволяет как бы "разобрать" объект и записать его части в несколько переменных, т. е. происходит деконструкция, "разборка". При этом исходный объект не меняется. Деструктор же отвечает за корректное уничтожение объекта, что совсем иное.
Спасибо за замечание. Я переводил максимально близко к оригинальному тексту и писал ссылки/указатели там, где про них писал автор. У меня тоже иногда возникало впечатление, что он случайно путал их, но я решил ничего не делать с этим: главное для меня было — не искажать смысл оригинального текста.
Из стандарта, 10.4 Абстрактные классы, параграф 6:
Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a virtual call (10.3) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undefined.
Если написать примитивно (т. е. просто переписать пример c Kotlin на C++), то да, код просто не скомпилируется. Но можно написать так, что все соберется и запустится. Вот пример кода, который приводит к UB.
Я просто хотел сказать, что передача по указателю не всегда быстрее передачи значения. Почему-то я постоянно слышу, что это так, хотя мои бенчмарки мне показывают обратную картину.
Если говорить о hot path, то да, его нужно тщательно оптимизировать уже на конкретных кейсах. Но в большинстве случаев при написании кода существенной разницы между передачей по указателю или передачей по значению не будет - это я и хотел доказать, и тем самым призвать читателей использовать то, что больше подходит по смыслу. Например, указатели могут быть
nil, и работать с ними тяжелее из-за одного дополнительного возможного значения.Спасибо за фидбэк.
Просто я регулярно слышу "надо передавать большие структуры по указателю, потому что так быстрее". И действительно без бенчмарков не всегда понятно, что быстрее: скопировать всю структуру в стеке или выделить её в куче и передавать указатель.
В статье не производится сравнение "выделять в куче или не выделять", а сравнивается "выделять в куче или копировать потенциально большую структуру каждый раз". Просто регулярно встречаю людей, которые переоценивают время копирования данных и считают это медленной операцией. А потом оправдывают этим использование указателей везде и всегда.
Цель этих бенчмарков не показать, что выделять в куче медленно - как вы верно заметили, это всем было понятно. Цель - показать, что копирование быстрое и в большинстве случаев быстрее, чем передавать указатели. Это инвалидирует один из аргументов сторонников везде передавать и возвращать указатели.
К сожалению, большая часть статьи получилась о бенчмарках, т. к. только производительность можно сравнить по численным характеристикам. Но я также привел аргументы про читаемость и семантические различия передачи значения и указателя.
Возможно, вам стоит посмотреть другие варианты, походить на собесы и сменить работу. Я сам устроился с полутора годами опыта на работу за 250к (go), при этом опыта фриланса у меня не было. Коллеги работают за примерно те же ±200к, у них тоже опыта полтора-два года. Разумеется, это зависит от стека и города, но я уверен, что можно получать больше 100к за то, чем вы занимаетесь.
У меня есть знакомые, которые тоже работают в небольших региональных компаниях за маленькие деньги, хотя могли бы сходить на собесы в компании побольше и с офисами в Москве/Питере и получать заметно больше денег.
Также если вы не меняете работу, то ваша зп может отстать от рыночной - я при каждом переходе получал сильно больше денег (а после первой работы зп выросла вообще в 2.5 раз).
Честно говоря, я бы почитал. Пишите!
Ну зачем так грубо. Я ещё даже не сеньор, а зп уже такая. И получал оферы на сильно больше.
Я не говорю, что все компании предлагают много денег, но я не могу согласиться, что все компании предлагают мало. Я сам видел вакансии, собеседовался и получал оферы от разных компаний, и зп в них отличалась очень сильно - мне предлагали и 100к в мелкой компании (при том, что у меня уже были оферы на 180к+), мне предлагали пообщаться о вакансии сеньора Go c 3-5 годами опыта с зп как раз где-то 200-300к или ниже (не помню) в каком-то регионе.
В целом я очень сильно удивляюсь, когда на собесе прошу казалось бы слишком большую зп, а мне согласуют офер на неё. Я считаю, надо ходить и пытаться проверять, где находится тот самый "потолок", выше которого тебе денег не дадут.
Спасибо за обратную связь.
А можете подсказать, что вы имеете в виду под объяснением причин проблем? Я вроде постарался везде описать, что и почему происходит, не вдаваясь в подробности и не рассказывая то, что Go разработчики уже наверняка знают. Считаете, что стоило побольше углубиться или что-то иное?
Про профи не соглашусь - все проблемы и примеры взяты из реального опыта, где разработчики среднего уровня и выше писали примерно такой код, при этом не задумываясь "а что если контекст отменится прямо тут?" и "если я использую каналы тут, к каким проблемам это приведет?". Я бы назвал их профи, но некоторые просто не задумывались о таких потенциальных проблемах, а уж тесты на такое писать вообще не каждый любит. А уж писать тесты на случаи кроме happy path - в моем опыте совсем редкость.
Спасибо, согласен. Надо проверки добавить в начале функции и возвращать сразу nil, если аргументы пустые.
Интересная ссылка, спасибо. Но там комментаторы как раз и указывают на то, что намного вероятнее проблема в коде приложения, чем в самом механизме генерации UUID или коллизиях.
Примеры:
Можете поделиться своими историями про коллизии?
Upd 1: вижу ниже подобное обсуждение, мой вопрос неактуален
Постараюсь ответить:
Декомпозиция обозвана деконструктором, т. к. деконструирует, "разбирает" значение в несколько переменных. Я использовал слово "деконструктор", т. к. по моему мнению так проще понять, что мы говорим о методе
Deconstruct(...). Ну и в документации это тоже называют деконструктором.Деконструктор — это же не то же самое, что и деструктор, и вовсе не антоним конструктора. Тут деконструктор позволяет как бы "разобрать" объект и записать его части в несколько переменных, т. е. происходит деконструкция, "разборка". При этом исходный объект не меняется. Деструктор же отвечает за корректное уничтожение объекта, что совсем иное.
ufo самое время забрать меня с этой планеты
Спасибо за замечание. Я переводил максимально близко к оригинальному тексту и писал ссылки/указатели там, где про них писал автор. У меня тоже иногда возникало впечатление, что он случайно путал их, но я решил ничего не делать с этим: главное для меня было — не искажать смысл оригинального текста.
Да, спасибо. Поправил.
Тут действительно имеются ввиду не простые числа (2, 3, 5, 7 и т.д.). "Просто числа" звучит однозначнее.
Из стандарта, 10.4 Абстрактные классы, параграф 6:
Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a virtual call (10.3) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undefined.
Если написать примитивно (т. е. просто переписать пример c Kotlin на C++), то да, код просто не скомпилируется. Но можно написать так, что все соберется и запустится. Вот пример кода, который приводит к UB.
Подробнее можно почитать на StackOverflow.