Вопрос по fasthttp: можно как нибудь запихать в RequestCtx инстанцию

условного типа Х которая будет предоставлена той горутиной, которая обрабатывает запрос?

при обработке каждого запроса создавать инстанцию невыгодно, создавать contention на shared инстанции тоже

а чем тебе sync.Pooll не решение?

надо бы запустить бенчмарк и посмотреть насколько высок contention overhead с sync.Pool'ом 🤔

https://go.dev/play/p/a6EgbF632nn contentionbench % go run bench.go -i 10_000_000 -g 10 -m shared 2022/08/06 12:38:39 goroutines: 10 2022/08/06 12:38:39 mode: shared 2022/08/06 12:38:50 took: 10.955198291s contentionbench % go run bench.go -i 10_000_000 -g 10 -m syncpool 2022/08/06 12:38:57 goroutines: 10 2022/08/06 12:38:57 mode: syncpool 2022/08/06 12:38:57 took: 120.561875ms contentionbench % go run bench.go -i 10_000_000 -g 10 -m per-goroutine 2022/08/06 12:39:05 goroutines: 10 2022/08/06 12:39:05 mode: per-goroutine 2022/08/06 12:39:05 took: 34.094542ms sync.Pool приблизительно в 3.5 раза менее эффективен чем per-goroutine

В чем проблема сделать shared map[goroutine_id]*X?

а разве на goroutine_id можно полагаться?

А почему нет?)

Ну видимо если они не пересоздаются - то да

А зачем?)

если будешь юзать синкпул не меняй и не трогай объект когда отдал его пулу

Для этого и создали контекст) конечно можно

естественно это не много, но зачем, если это лишний overhead? 🙂 если же конечно fasthttp не предоставляет возможности некой goroutine-local memory, тогда, разумеется, ответ (sync.Pool) очевиден

еще раз… ты вообще способен разницу намерять не на синтетическом тесте, а на реальной нагрузке с реальными обработчиками? если нет - не надо компостировтаь мозги себе и товарищам. я, глядя на 10M итераций и 110ms разницы, уверен, что нет, не сможешь ты там ничего намерять

https://go.dev/play/p/PhinZ6ijNSH 2022/08/06 13:11:50 goroutines: 10 2022/08/06 13:11:50 modes: [per-goroutine syncpool atomicindex sharedinst] 2022/08/06 13:11:50 mode per-goroutine (21.16ms) 2022/08/06 13:11:50 mode syncpool (60.95625ms) 2022/08/06 13:11:54 mode atomicindex (3.846955542s) 2022/08/06 13:11:59 mode sharedinst (5.728765416s) надеюсь, ошибок не допустил, но не вариант

более того, atomicindex кидает data race

слушай, ну этот канал дети же читают! чему ты их учишь? тому, что не надо брать решение в лоб, если оно на 0.001% дороже?

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

вот-вот… @Romshark , смотри, что ты натворил 🙂

буду добавлять дисклеймер для <middle 😅 ДИСКЛЕЙМЕР ⚠️: данное техническое решение не рекомендуется к использованию ⛔️. Я не несу ответственность за баги в вашем проде и прожжённые бюджеты ваших проектов в случае попыток применить их в вашем продакшене

если серьезно, то “оптимизировать” то, что даже теоретически может дать максимум 0.1% прироста - это не “оптимизировать” называется, а “время просирать”

Мне очень лень доставать свои старые кейсы где это дало 30%

да и не надо. такие кейсы могут быть вполне, хоть я и не сталкивался. но кейс Романа явно не из этих

а как можно предполагать что мой кейс не из этих даже не зная моего кейса? 😅