Optimize BuildBidderNameHashSet

[linux019]

Pprof identified big amount of allocations caused by each call to CoreBidderNames on each auction request By storing result of CoreBidderNames into a single variable number of allocations reduced 4x

go test -benchmem -v -bench=Bench ./openrtb_ext/. |prettybench

Before:

BenchmarkBuildBidderNameHashSet
PASS
benchmark                             iter      time/iter   bytes alloc         allocs
---------                             ----      ---------   -----------         ------
BenchmarkBuildBidderNameHashSet-18   50244    22.66 μs/op    21333 B/op   12 allocs/op
ok      github.com/prebid/prebid-server/v2/openrtb_ext  1.415s

After:

BenchmarkBuildBidderNameHashSet
PASS
benchmark                              iter       time/iter   bytes alloc        allocs
---------                              ----       ---------   -----------        ------
BenchmarkBuildBidderNameHashSet-18   152774   7813.00 ns/op    10312 B/op   3 allocs/op
ok      github.com/prebid/prebid-server/v2/openrtb_ext  1.309s

[SyntaxNode]

The coreBidderNames slice can be altered by calls to SetAliasBidderName during startup. Could you please confirm all calls to the optimized BuildBidderNameHashSet occur after any potenital call to SetAliasBidderName ?

.. or to be safe, is it possible for SetAliasBidderName to reset the state of the optimized builder?

[linux019]

main() calls LoadBidderInfoFromDisk https://github.com/prebid/prebid-server/blob/5b11f59bdde56d7b22678efb4b3dfb2da9c62a7f/main.go#L35 Next is creates a HTTP server where a call to auction endpoint triggers BuildBidderNameHashSet Yes if new changes will call SetAliasBidderName this cached set needs to be rebuilt.

[bsardo]

Tagging as blocked. Another PR is in flight that will address the raised concerns.