Рекомендую sqlboiler, чутка доки покурить надо конечно, но потом втянешься

А gorm - ослобык, и не быстрый и не человечный

А еще на нем можно таких проблем огребсти случайно, что просто пиздц. Я его больше года использую (сейчас бы я его, конечно, не выбрал, но и не я его выбирал вначале). Например если сделать db.Delete("users").Where("id = ?", id) то вы снесете всю таблицу юзеров, лол

жесть)

Капец

типа чистый sql лучше?

А еще на нем можно таких проблем огребсти случайно, что просто пиздц. Я его больше года использую (сейчас бы я его, конечно, не выбрал, но и не я его выбирал вначале). Например если сделать db.Delete("users").Where("id = ?", id) то вы снесете всю таблицу юзеров, лол

Почему так?

Всем привет! Народ, подскажите как происходит освобождение памяти и как правльно это сделать? Есть такой код: type SomeObject struct { data string } func NewObject() *SomeObject { obj:=&SomeObject{ data: "default value", } return obj } func main() { var list map[int]*SomeObject list[0]=NewObject() log.Println(list[0].data) delete (list,0) } Насколько я понимаю delete удаляет только указатель, а память остается занятой структурой. Как удалить (delocate memory) саму структуру из памяти?

Всем привет! Народ, подскажите как происходит освобождение памяти и как правльно это сделать? Есть такой код: type SomeObject struct { data string } func NewObject() *SomeObject { obj:=&SomeObject{ data: "default value", } return obj } func main() { var list map[int]*SomeObject list[0]=NewObject() log.Println(list[0].data) delete (list,0) } Насколько я понимаю delete удаляет только указатель, а память остается занятой структурой. Как удалить (delocate memory) саму структуру из памяти?

В го работает автоматический сборщик мусора, это его особенность, он автоматом освободит память через какое-то время, если на объект не осталось ссылок

Почему так?

Ну потому, что gorm сначала выполнит Delete, а потом только Where (точнее он его проигнорирует). По задумке Delete надо писать как Delete("users", "id = ?", id)

Ахаххахах.

В го работает автоматический сборщик мусора, это его особенность, он автоматом освободит память через какое-то время, если на объект не осталось ссылок

Т.е. если на созданную структур нет указателей, то GC её автоматом позже почистит ?

Т.е. если на созданную структур нет указателей, то GC её автоматом позже почистит ?

да

А еще на нем можно таких проблем огребсти случайно, что просто пиздц. Я его больше года использую (сейчас бы я его, конечно, не выбрал, но и не я его выбирал вначале). Например если сделать db.Delete("users").Where("id = ?", id) то вы снесете всю таблицу юзеров, лол

Ты не почитал доки об апи либы и ноешь, что она сделала что-то не то?

Всем привет! Народ, подскажите как происходит освобождение памяти и как правльно это сделать? Есть такой код: type SomeObject struct { data string } func NewObject() *SomeObject { obj:=&SomeObject{ data: "default value", } return obj } func main() { var list map[int]*SomeObject list[0]=NewObject() log.Println(list[0].data) delete (list,0) } Насколько я понимаю delete удаляет только указатель, а память остается занятой структурой. Как удалить (delocate memory) саму структуру из памяти?

delete просто удаляет элемент из хеш-таблицы, больше он вообще ничего не делает

Rand.intn(10) < 3 даже

Надо же ещё сид через время юникс задать и тогда по ОТВ все абсолютно верно

Т.е. если на созданную структур нет указателей, то GC её автоматом позже почистит ?

Но! будьте внимательны, если у вас останется где-то горутина, которая крутится сама по себе, безз всяких каналов управления, то этот мусор может жить вечно, тк внутри этих горутин указатели еще существуют и GC его не соберет

Но! будьте внимательны, если у вас останется где-то горутина, которая крутится сама по себе, безз всяких каналов управления, то этот мусор может жить вечно, тк внутри этих горутин указатели еще существуют и GC его не соберет

Ясно.

типа чистый sql лучше?

Ну да, лучше использовать билдеры запросов типа squirrel

delete просто удаляет элемент из хеш-таблицы, больше он вообще ничего не делает

Вот это меня навело на размышление... что удаляется только элемент мапы...

Особенность, потому как GC тормозит основной поток чтобы собрать мусор, что негативно отразится на реалтайм данных

Ты не почитал доки об апи либы и ноешь, что она сделала что-то не то?

Горм слишком много делает всего "не того"

Особенность, потому как GC тормозит основной поток чтобы собрать мусор, что негативно отразится на реалтайм данных

Интересненько

Интересненько

те если вы будуте генерить постоянно большое число объектов, то даже при выводе в лог, сможете увидеть как GC тормозит рантайм для сбора мусора....

А еще на нем можно таких проблем огребсти случайно, что просто пиздц. Я его больше года использую (сейчас бы я его, конечно, не выбрал, но и не я его выбирал вначале). Например если сделать db.Delete("users").Where("id = ?", id) то вы снесете всю таблицу юзеров, лол

Так в доках вроде это и написано было

Особенность, потому как GC тормозит основной поток чтобы собрать мусор, что негативно отразится на реалтайм данных

А что конкретно происходит когда я создаю ререиенную и не использую ее в коде?Почему выдаеь ошибку компиляции?

Ну да, лучше использовать билдеры запросов типа squirrel

+

Но! будьте внимательны, если у вас останется где-то горутина, которая крутится сама по себе, безз всяких каналов управления, то этот мусор может жить вечно, тк внутри этих горутин указатели еще существуют и GC его не соберет

Да. Это понимаю... В итоге остается только неактивная структура без указателей на нее... Поэтому хотел убедиться, что при создании таких структур и последующем удалении указателей на них память не засрется...

А что конкретно происходит когда я создаю ререиенную и не использую ее в коде?Почему выдаеь ошибку компиляции?

Компилятор не пропускает такое варворство, тк по логиге разрабов нечего плодить переменные которые ведут в никуда, по началу жудко бесит, но потом смиряешься

Да. Это понимаю... В итоге остается только неактивная структура без указателей на нее... Поэтому хотел убедиться, что при создании таких структур и последующем удалении указателей на них память не засрется...

Не засрется.) Можно расслабиться, тут не ся, и следить за памятью не надо, это уже сделали за вас)

Не засрется.) Можно расслабиться, тут не ся, и следить за памятью не надо, это уже сделали за вас)

Это очень радует! Спасибо!

Компилятор не пропускает такое варворство, тк по логиге разрабов нечего плодить переменные которые ведут в никуда, по началу жудко бесит, но потом смиряешься

Есть такое. Хотя чуствую себя иногда мол меня оградили в памяти. После Java довольно интересный был этот момент и дофига моментов синтаксиса хотя-бы то, что точки с запятой не нужно ставить , скобки в циклах и условиях ,а так же отсутствие while .

Есть такое. Хотя чуствую себя иногда мол меня оградили в памяти. После Java довольно интересный был этот момент и дофига моментов синтаксиса хотя-бы то, что точки с запятой не нужно ставить , скобки в циклах и условиях ,а так же отсутствие while .

for bool {} работает в точности как while

Есть такое. Хотя чуствую себя иногда мол меня оградили в памяти. После Java довольно интересный был этот момент и дофига моментов синтаксиса хотя-бы то, что точки с запятой не нужно ставить , скобки в циклах и условиях ,а так же отсутствие while .

Ну это скорее для читаемости кода, чтобы другой после тебя сел и смог разобраться что к чему

for bool {} работает в точности как while

Это я знаю,но сам факт

Так в доках вроде это и написано было

ага, я использую горм еще с тех времен, как чтобы разобраться как он работает, приходилось лезть в исходники и тесты, так что я на нем собаку съел.

Ну это скорее для читаемости кода, чтобы другой после тебя сел и смог разобраться что к чему

Я понимаю,но отсутствие точки с запятой всеравно меня ещё долго удивлять будет.

Надеюсь GC когда - нибудь допилят чтобы он в рантайме подчищал мусор без остановки рантайма

Надеюсь GC когда - нибудь допилят чтобы он в рантайме подчищал мусор без остановки рантайма

runtime.GC() Я так понимаю это принудительный вызов GC ?

ага, я использую горм еще с тех времен, как чтобы разобраться как он работает, приходилось лезть в исходники и тесты, так что я на нем собаку съел.

Радует что gorm развивается

да, но зачем? (https://golang.org/pkg/runtime/#GC)

да, но зачем? (https://golang.org/pkg/runtime/#GC)

Хз.... Но для чего-то функцию реализовали))

Надеюсь GC когда - нибудь допилят чтобы он в рантайме подчищал мусор без остановки рантайма

В го concurrent mark and sweep gc, почитай как он работает, он делает очень маленькую паузу на фазе initial mark, а потом мусор собирает уже конкурентно

В го concurrent mark and sweep gc, почитай как он работает, он делает очень маленькую паузу на фазе initial mark, а потом мусор собирает уже конкурентно

Да, я в курсе, но он делает эту паузу, я пробовал делать канал объектов из одной в другую горутину, в секунду через канал проходило порядка 10000к структур, в логе в терминале видно было остановку рантайма

Хз.... Но для чего-то функцию реализовали))

Для специфичных нужд. И для параноиков)

Да, я в курсе, но он делает эту паузу, я пробовал делать канал объектов из одной в другую горутину, в секунду через канал проходило порядка 10000к структур, в логе в терминале видно было остановку рантайма

неизвестно как у тебя логгер еще устроен был, может у тебя io логгера просто блокировало главный поток сбрасывая какой нить буффер или прочую хрень

неизвестно как у тебя логгер еще устроен был, может у тебя io логгера просто блокировало главный поток сбрасывая какой нить буффер или прочую хрень

Нет, логер стандартный, ошибок небыло, тк тест был синтетический и данные в структуру генирировались на лету. Это однозначно сборка мусора, тк через равные промежутки и видно было как память потребляемая приложением плавает

Вот сейчас над переиспользованием структур через sync.Pool вроде

Суть в том, что после того как работа сделана, структура не удаляется, а отправляется обратно в пул, после чего ты можешь ее повторно запросить

Но надо делать бенчи, что будет быстрее работать

Суть в том, что после того как работа сделана, структура не удаляется, а отправляется обратно в пул, после чего ты можешь ее повторно запросить

Сложность в том, что структуру надо "очищать" после использования

Это да, надо доп метод, который будет приводить структуру в порядок

ну когда ты гоняешь миллион тяжелых структур туда - сюда обратно, это может иметь смысл

Надо пробовать, пока руки не добрались, но в голове уже поселилось

типа чистый sql лучше?

Типа внизапна это DSL.

не может быть)

не может быть)

Приколись?! Сам как узнал, еле пивом отпоили

а от sequel вообще скупая слеза побёгла

Сложность в том, что структуру надо "очищать" после использования

?! Можете уточнить, что значит очищать?! Все поля в nil. Завершение горутин с этой структурой?! Вопрос относительно конкретной задачи: Использую websocket сервер. При подключении нового клиента создаётся структура, в которую передается ссылка на экземпляр клиентского коннекта. Ссылка на экземпляр структуры добавляется в map. При наступлении события клиентского дисконнекта я останавливаю все горутин в конкретной структуре, удаляю из map элемент со ссылкой на структуру с "отвалившимся" коонектом. Как я понял gc позаботится об остальном и дополнительно мне ничего делать не надо. Или не совсем так?!

?! Можете уточнить, что значит очищать?! Все поля в nil. Завершение горутин с этой структурой?! Вопрос относительно конкретной задачи: Использую websocket сервер. При подключении нового клиента создаётся структура, в которую передается ссылка на экземпляр клиентского коннекта. Ссылка на экземпляр структуры добавляется в map. При наступлении события клиентского дисконнекта я останавливаю все горутин в конкретной структуре, удаляю из map элемент со ссылкой на структуру с "отвалившимся" коонектом. Как я понял gc позаботится об остальном и дополнительно мне ничего делать не надо. Или не совсем так?!

Так, так, мы говорили про пул структур, чтобы их не пересоздавать каждый раз, а создать и использовать по кругу

ERROR: S client not available

?! Можете уточнить, что значит очищать?! Все поля в nil. Завершение горутин с этой структурой?! Вопрос относительно конкретной задачи: Использую websocket сервер. При подключении нового клиента создаётся структура, в которую передается ссылка на экземпляр клиентского коннекта. Ссылка на экземпляр структуры добавляется в map. При наступлении события клиентского дисконнекта я останавливаю все горутин в конкретной структуре, удаляю из map элемент со ссылкой на структуру с "отвалившимся" коонектом. Как я понял gc позаботится об остальном и дополнительно мне ничего делать не надо. Или не совсем так?!

Не забудь только мапу мьютексом обвешать, а то получишь ошибку конкуретного достпа

Так, так, мы говорили про пул структур, чтобы их не пересоздавать каждый раз, а создать и использовать по кругу

sync.Pool ?! Это необходимо для особых случаев требующих оптимизации или рекомендуется всегда когда множество стуртур. В моем случае это необходимо?!

sync.Pool ?! Это необходимо для особых случаев требующих оптимизации или рекомендуется всегда когда множество стуртур. В моем случае это необходимо?!

не переживайте, это не ваш случай

Не забудь только мапу мьютексом обвешать, а то получишь ошибку конкуретного достпа

Это да.. благодарю.. про это Забыл)))

?! Можете уточнить, что значит очищать?! Все поля в nil. Завершение горутин с этой структурой?! Вопрос относительно конкретной задачи: Использую websocket сервер. При подключении нового клиента создаётся структура, в которую передается ссылка на экземпляр клиентского коннекта. Ссылка на экземпляр структуры добавляется в map. При наступлении события клиентского дисконнекта я останавливаю все горутин в конкретной структуре, удаляю из map элемент со ссылкой на структуру с "отвалившимся" коонектом. Как я понял gc позаботится об остальном и дополнительно мне ничего делать не надо. Или не совсем так?!

Суть в том, что бывает, что нам очень часто нам надо создавать много объектов, например какие-то DTO-структуры или прочее и в теории их срок жизни очень маленький, но они накапливаются и висят в памяти, пока их сборщик не соберет. Для этого придумали sync.Pool, он по случаю создает новый объект либо вытаскивает уже существующий, если его не собрал сборщик, а ты объект понасиловал и сбросил обратно в пул. Так вот, после возвращения обратно в пул, у тебя у объекта остаются все старые значения свойств и если ты его снова получишь из пула, он будет замусорен старыми значениями

sync.Pool ?! Это необходимо для особых случаев требующих оптимизации или рекомендуется всегда когда множество стуртур. В моем случае это необходимо?!

Я недавно юзал sync.Map из go1.9. Сначала начитался, что мол лучше по классике через rwmutex, но потом всё переписал на sync.Map и оказалось проще и быстрей. Это так, просто к слову.

Конкретно sync.Pool не доводилось юзать.

Я недавно юзал sync.Map из go1.9. Сначала начитался, что мол лучше по классике через rwmutex, но потом всё переписал на sync.Map и оказалось проще и быстрей. Это так, просто к слову.

в каком плане быстрее? в плане писанины? или делал бенчи?

в каком плане быстрее? в плане писанины? или делал бенчи?

В плане писанины скорее.

А бенчи вот тут есть: https://habrahabr.ru/post/338718/

Но для меня это было некритично.

В плане писанины скорее.

» если у вас высоконагруженная (и 100нс решают) система с большим количеством ядер процессора (32+), вы можете захотеть использовать sync.Map вместо стандартного map+sync.RWMutex. В остальных случаях, sync.Map особо не нужен. порадовало))))

» если у вас высоконагруженная (и 100нс решают) система с большим количеством ядер процессора (32+), вы можете захотеть использовать sync.Map вместо стандартного map+sync.RWMutex. В остальных случаях, sync.Map особо не нужен. порадовало))))

Я хз зачем вот такое пишут. Системные либы для того и делают, чтобы проще было. В итоге так и получилось, вместо постоянных блокировок-разблокировок, там всё в несколько строчек делается.

Суть в том, что бывает, что нам очень часто нам надо создавать много объектов, например какие-то DTO-структуры или прочее и в теории их срок жизни очень маленький, но они накапливаются и висят в памяти, пока их сборщик не соберет. Для этого придумали sync.Pool, он по случаю создает новый объект либо вытаскивает уже существующий, если его не собрал сборщик, а ты объект понасиловал и сбросил обратно в пул. Так вот, после возвращения обратно в пул, у тебя у объекта остаются все старые значения свойств и если ты его снова получишь из пула, он будет замусорен старыми значениями

Очень доступное объяснение. Теперь все понятно. Спасибо!!

» если у вас высоконагруженная (и 100нс решают) система с большим количеством ядер процессора (32+), вы можете захотеть использовать sync.Map вместо стандартного map+sync.RWMutex. В остальных случаях, sync.Map особо не нужен. порадовало))))

Ну он работает немного по-другому https://golang.org/src/sync/map.go?m=text Там внутри две мапы, одна dirty map[interface{}]*entry, а вторая как read atomic.Value И оптимизация за счет жонглирования данных между ними

Я хз зачем вот такое пишут. Системные либы для того и делают, чтобы проще было. В итоге так и получилось, вместо постоянных блокировок-разблокировок, там всё в несколько строчек делается.

Sync.Map разрабатывался для многоядерных систем. Там он работает быстрей. Если потоков мало, то быстрей работаеет стандартный map с мютексом.

Кто-то рассказывал что синк мап хранит копию мапы, не очень хорошее решение для больших мап

Кто-то рассказывал что синк мап хранит копию мапы, не очень хорошее решение для больших мап

Сэр слышал про copy-on-write ?

Sync.Map разрабатывался для многоядерных систем. Там он работает быстрей. Если потоков мало, то быстрей работаеет стандартный map с мютексом.

У меня это даже близко не было боттлнеком, так что писал, как удобней было ¯\_(ツ)_/¯

Сэр слышал про copy-on-write ?

ну если не хватат капасити, то да ?

Посоны, а что делать если я итерирую по массиву но мне не нужен индекс и у меня declared and not used

замени имя переменной на нижнее подчеркивание _

_, val := range ...

Вы лучшие! Пошёл про это подчеркиваниие гуглить

Вы лучшие! Пошёл про это подчеркиваниие гуглить

а что про него гуглить, если надо что-то отправить в небытие - юзай _

Уже прочитал. Это такой /dev/null :)

Уже прочитал. Это такой /dev/null :)

Ошибки только туда не отправляйте.

Ошибки только туда не отправляйте.

Не буду

Всем привет! Подскажите как можно подобную структуру создавать или генерировать? type Resp struct { Key struct { // Данные в массиве } `json:"special_key"` } От сервера приходит ответ в JSON в формате { "special_key" : { "data" : data ... } } То есть ключ в ассоциативном массиве меняется исходя из того какой я ключ отправлю на сервер. Как это можно реализовать?

json.RawMessage + свой анмаршаллер