поддержу
сложить два может оказаться недостаточно, а вот если по таким данным посчитать комиссии, профитлос, да по нескольким позициям, то расхождение в значащих цифрах получить получить уже реально
в 18м году тестить одинарные и двойные кавычки это конечно жесть ))
помню как бомбило, когда в подобных спорах, этак 8-10 назад ссылались лохматую статью начала 2000х, выглядело это как язычество
В современном обществе потребления это мало кого волнует. Автопроизводители уже не производят вечных машин. Потребители по окончании гарантии авто меняют. Т.е. заявленный производителем ресурс 100-150ткм (для некоммерческого транспорта) двигателя и кпп ходят.
Владельцам же подержаных машин с этим приходится мириться. В этом случае проще и дешевле заменить агрегат целиком на контрактный.
На ниссанах довели до ума вариатор. Если в начале они были проблемой на кашкае и мурано, то года после 08го с вариатором проблем не больше чем с автоматом, даже на двигателях 2.5/3.5л. и 4wd. Последние модели все выпускаются с CVT (исключая альмеру и террано, но все знают что это неправильная альмера и неправильный террано)
Помню, когда массово начали ввозить бу иномарки из японии, очень недоверчиво относились к автоматам. Сейчас автоматом никого не напугаешь.
То же самое, как мне кажется, произошло и с вариаторами, ошибки найдены и исправлены, ресурс соизмерим с ресурсами современных двигателей. При этом размер вариатора очень важное преимущество — размер, что важно для авто с поперечным расположением двигателя и кпп. Старые 4хступенчатые автоматы AT очень надежны, но при этом из-за малого кол-ва передач туповаты и неэффективны (ну разве что за городом). Увеличение кол-ва передач требует либо увеличение размеров акпп либо уменьшение размеров деталей.
Следующий этап за преселективными роботами имха
В этом есть какая-то магия? Просто не работал с пакетом unsafe.
Есть какие-нибудь тесты, которые подтверждают облегчение жизни gc при использовании sync.Map?
В коде вижу вот это: return &entry{p: unsafe.Pointer(&i)}
создается ссылка на entry и далее она хранится в map[interface{}]*entry
Сокращения кол-ва ссылок не вижу, плюс объект, ссылка на который сохранена в map, продолжает жить в куче. В чем профит.
согласен, кроме последнего предложения
sync.Map не решит проблему с gc, т.к. хранящиеся в мапке указатели никуда не денутся
здесь только один путь — уменьшать кол-во указателей, как, например, сделали вот эти ребята: allegro.tech/2016/03/writing-fast-cache-service-in-go.html
по поводу defer
i5-4670 CPU @ 3.40GHz goos: linux
goarch: amd64
BenchmarkLockUnlock-4 100000000 15.0 ns/op
BenchmarkLockDeferUnlock-4 30000000 44.9 ns/op
PASS
здесь один метод вообще лишний, оставить только GC и стартовать его в функции New
еще 5 копеек
— не стоит светить все функции наружу, тот же GC, есть интерфейс Get/Set/Delete остальные функции не должны быть доступны снаружи
— defer не бесплатен, когда функции делает много под блокировкой, это оправдано, для чтения/записи в map это избыточно
— не надо держать блокировку без необходимости, получил блокировку, прочитал/записал в мапку, отпустил блокировку и дальше уже разбираешься с тем что получил (это про Get)
— зачем delete возврат ошибки? она бесполезна + ради этого двойной поиск в мапке
— сборка мусора вообще странно сделана, зачем в два этапа? нет гарантии что между expiredKeys и clearItems значения не будут обновлены
Ну и довольно медленный он, по крайней мере по сравнению с мьютексами
Сам бенчмарков не делал, столь категорично утверждать не буду, но как универсальное решение тоже бы не посоветовал.
Документация описывает 2 конкретных случаях, когда sync.Map выгоднее мапки с мьютексом, но в общем случае для реализации кеша может сыграть как в плюс так и в минус.
Было интересно кроме самих цифр увидеть какой-то анализ, почему в одних случаях разница между 7.0/7.1/7.2 существенна а в других нет, или почему так выбивается laravel c hhvm?
иногда меняются, и вот конкретно этот момент мне не понятен, как доставить клиенту изменившиеся данные, пока не протух кеш
сложить два может оказаться недостаточно, а вот если по таким данным посчитать комиссии, профитлос, да по нескольким позициям, то расхождение в значащих цифрах получить получить уже реально
тратим на написание if err != nil ))
помню как бомбило, когда в подобных спорах, этак 8-10 назад ссылались лохматую статью начала 2000х, выглядело это как язычество
прям таки и не любят? откуда это заблуждение?
Владельцам же подержаных машин с этим приходится мириться. В этом случае проще и дешевле заменить агрегат целиком на контрактный.
То же самое, как мне кажется, произошло и с вариаторами, ошибки найдены и исправлены, ресурс соизмерим с ресурсами современных двигателей. При этом размер вариатора очень важное преимущество — размер, что важно для авто с поперечным расположением двигателя и кпп. Старые 4хступенчатые автоматы AT очень надежны, но при этом из-за малого кол-ва передач туповаты и неэффективны (ну разве что за городом). Увеличение кол-ва передач требует либо увеличение размеров акпп либо уменьшение размеров деталей.
Следующий этап за преселективными роботами имха
Есть какие-нибудь тесты, которые подтверждают облегчение жизни gc при использовании sync.Map?
В коде вижу вот это:
return &entry{p: unsafe.Pointer(&i)}создается ссылка на entry и далее она хранится в
map[interface{}]*entryСокращения кол-ва ссылок не вижу, плюс объект, ссылка на который сохранена в map, продолжает жить в куче. В чем профит.
sync.Map не решит проблему с gc, т.к. хранящиеся в мапке указатели никуда не денутся
здесь только один путь — уменьшать кол-во указателей, как, например, сделали вот эти ребята: allegro.tech/2016/03/writing-fast-cache-service-in-go.html
i5-4670 CPU @ 3.40GHz
goos: linux
goarch: amd64
BenchmarkLockUnlock-4 100000000 15.0 ns/op
BenchmarkLockDeferUnlock-4 30000000 44.9 ns/op
PASS
еще 5 копеек
— не стоит светить все функции наружу, тот же GC, есть интерфейс Get/Set/Delete остальные функции не должны быть доступны снаружи
— defer не бесплатен, когда функции делает много под блокировкой, это оправдано, для чтения/записи в map это избыточно
— не надо держать блокировку без необходимости, получил блокировку, прочитал/записал в мапку, отпустил блокировку и дальше уже разбираешься с тем что получил (это про Get)
— зачем delete возврат ошибки? она бесполезна + ради этого двойной поиск в мапке
— сборка мусора вообще странно сделана, зачем в два этапа? нет гарантии что между expiredKeys и clearItems значения не будут обновлены
Сам бенчмарков не делал, столь категорично утверждать не буду, но как универсальное решение тоже бы не посоветовал.
Документация описывает 2 конкретных случаях, когда sync.Map выгоднее мапки с мьютексом, но в общем случае для реализации кеша может сыграть как в плюс так и в минус.
sqle это про удобство а не про производительность