MB
Size: a a a
2020 May 02
АП
можно
АП
*string
АП
указатель может указывать на string или быть пустым
АП
или на любой другой тип может указывать или нет
АП
func saveImage(r *http.Request, imageName string) *string
АП
return nil
-- OR ---
return &stringVar
-- OR ---
return &stringVar
IS
С чем связано, что синк мапа при большем числе ядер выигрывает?
Вот тут есть график при разных ядрах https://medium.com/@deckarep/the-new-kid-in-town-gos-sync-map-de24a6bf7c2c
Вот тут есть график при разных ядрах https://medium.com/@deckarep/the-new-kid-in-town-gos-sync-map-de24a6bf7c2c
С тем, как и для каких целей она сделана.
MB
указатель может указывать на string или быть пустым
прикольно спасибо
АП
прикольно спасибо
проверяйте указатели на пустоту (nil) только перед использованием
АП
иначе паника если он nil
АП
для получения значения надо его получить будет "разменовывание указателей" это myStringVal = *returnedString
IS
Вообще вижу в исходниках синкмапы, что она как atomic юзает, но в определенной ситуации откатывается к mutex.
Atomic может выигрывать по скорости.
Atomic может выигрывать по скорости.
Синк мап нужно выбирать по назначению, а не по тому что она использует внутри. В доке описаны два случая когда она подходит. Во всех остальных случаях обычная мапа с мютексом скорее всего будет лучше.
АМ
Ребят, так же написал мидлвэа для чи для сбора метрик прометеус. Забирайте кому нужно, или используйте для примера
https://github.com/m8as/go-chi-metrics
https://github.com/m8as/go-chi-metrics
ЛА
Синк мап нужно выбирать по назначению, а не по тому что она использует внутри. В доке описаны два случая когда она подходит. Во всех остальных случаях обычная мапа с мютексом скорее всего будет лучше.
Все же интересны детали реализации.
Сейчас долго въезжал в исходник, он очень сложный для понимания, хотя кода на пару страниц.
Выходит так, что синкмап хранит 2 мапы внутри себя, одна только чтения - read - для доступа к ней локи не ставятся, вторая - для записи - dirty (с ней лок ставится).
Поначалу все данные попадают в dirty и по сути у нас работает алгоритм мапы с локом. Но синкмапа считает кол-во раз сколько мы запросили элемент из dirty. Если это кол-во становится больше чем число элементов в dirty, то текущая dirty сеттится в свойство read.
Довольно сложная логика, в которой я бы не сказал что все успехи и недостатки определяются всего двумя пунктами из доки...
То что доступ к read выполняется без локов вообще может дать синкмапе выйгрыш в скорости по сравнению с мапой с мьютексом.
Сейчас долго въезжал в исходник, он очень сложный для понимания, хотя кода на пару страниц.
Выходит так, что синкмап хранит 2 мапы внутри себя, одна только чтения - read - для доступа к ней локи не ставятся, вторая - для записи - dirty (с ней лок ставится).
Поначалу все данные попадают в dirty и по сути у нас работает алгоритм мапы с локом. Но синкмапа считает кол-во раз сколько мы запросили элемент из dirty. Если это кол-во становится больше чем число элементов в dirty, то текущая dirty сеттится в свойство read.
Довольно сложная логика, в которой я бы не сказал что все успехи и недостатки определяются всего двумя пунктами из доки...
То что доступ к read выполняется без локов вообще может дать синкмапе выйгрыш в скорости по сравнению с мапой с мьютексом.
ЛА
Да, апдейт данных из read тоже работает быстрее обычной мапы.