proposal: sync.Map: generic sync.Map version

[Gaudeamus]

Proposal Details

I've tried to implement generic version of sync.Map and tests shows significant performance improvements
The test are passed. I'm not sure, could such a boost be caused only by generic approach without changing the underlying logic?

https://github.com/Gaudeamus/syncMapGeneric

                                                          │   classic     │                generic                │
                                                          │   sync.Map    │                syncMap                │
------------------------------------------------------------------------------------------------------------------│                                                    
                                                          │    sec/op     │    sec/op      vs base                │
LoadMostlyHits/*syncmap.SyncMap[int,int]-10                  3.460n ±  6%    1.025n ± 16%  -70.38% (p=0.000 n=10)
LoadMostlyMisses/*syncmap.SyncMap[int,int]-10                2.264n ±  3%    1.228n ± 11%  -45.77% (p=0.000 n=10)
LoadOrStoreBalanced/*syncmap.SyncMap[int,int]-10             310.1n ±  2%    206.5n ± 29%  -33.40% (p=0.000 n=10)
LoadOrStoreUnique/*syncmap.SyncMap[int,int]-10               562.4n ±  7%    412.5n ±  6%  -26.66% (p=0.000 n=10)
LoadOrStoreCollision/*syncmap.SyncMap[int,int]-10           2.9290n ± 34%   0.7798n ± 22%  -73.38% (p=0.000 n=10)
LoadAndDeleteBalanced/*syncmap.SyncMap[int,int]-10           4.242n ± 35%    1.468n ±  5%  -65.38% (p=0.000 n=10)
LoadAndDeleteUnique/*syncmap.SyncMap[int,int]-10            1.8440n ± 41%   0.5278n ±  1%  -71.37% (p=0.000 n=10)
LoadAndDeleteCollision/*syncmap.SyncMap[int,int]-10          3.856n ± 26%    1.060n ± 13%  -72.51% (p=0.000 n=10)
Range/*syncmap.SyncMap[int,int]-10                           1.331µ ± 23%    1.280µ ±  9%   -3.83% (p=0.025 n=10)
AdversarialAlloc/*syncmap.SyncMap[int,int]-10                199.2n ±  8%    156.9n ±  9%  -21.23% (p=0.001 n=10)
AdversarialDelete/*syncmap.SyncMap[int,int]-10               38.56n ±  9%    34.69n ± 10%  -10.05% (p=0.004 n=10)
DeleteCollision/*syncmap.SyncMap[int,int]-10                1.4440n ± 41%   0.5640n ±  8%  -60.94% (p=0.000 n=10)
SwapCollision/*syncmap.SyncMap[int,int]-10                   165.7n ±  2%    121.8n ±  2%  -26.50% (p=0.000 n=10)
SwapMostlyHits/*syncmap.SyncMap[int,int]-10                  28.73n ± 33%    13.44n ±  7%  -53.24% (p=0.000 n=10)
SwapMostlyMisses/*syncmap.SyncMap[int,int]-10                601.4n ±  7%    520.1n ±  3%  -13.52% (p=0.000 n=10)
CompareAndSwapCollision/*syncmap.SyncMap[int,int]-10        13.885n ± 21%    6.327n ± 10%  -54.43% (p=0.000 n=10)
CompareAndSwapNoExistingKey/*syncmap.SyncMap[int,int]-10    2.3880n ±  3%   0.5291n ±  1%  -77.84% (p=0.000 n=10)
CompareAndSwapValueNotEqual/*syncmap.SyncMap[int,int]-10    3.1185n ± 32%   0.9878n ± 16%  -68.32% (p=0.000 n=10)
CompareAndSwapMostlyHits/*syncmap.SyncMap[int,int]-10        20.18n ±  7%    10.39n ± 14%  -48.51% (p=0.000 n=10)
CompareAndSwapMostlyMisses/*syncmap.SyncMap[int,int]-10      6.510n ± 47%    1.131n ± 27%  -82.62% (p=0.000 n=10)
CompareAndDeleteCollision/*syncmap.SyncMap[int,int]-10      12.320n ± 17%    5.797n ± 10%  -52.95% (p=0.000 n=10)
CompareAndDeleteMostlyHits/*syncmap.SyncMap[int,int]-10      28.18n ± 15%    10.50n ± 18%  -62.73% (p=0.000 n=10)
CompareAndDeleteMostlyMisses/*syncmap.SyncMap[int,int]-10    2.272n ± 39%    1.389n ±  5%  -38.90% (p=0.007 n=10)
geomean                                                      17.76n          8.085n        -54.47%

[ianlancetaylor]

I don't see a proposal here. Are you asking a question? Questions and discussions in general are better handled in a forum such as golang-dev. See https://go.dev/wiki/Questions. Thanks.

Yes, the generic approach can be faster in some cases, because it can reduce the overhead required for interface boxing and interface method calls.

I'm going to close this issue. Please comment if you disagree.

[fzipp]

Also, duplicate of #47657

[Gaudeamus]

I understand benefits of generic Vs interface. Question arises only because, I don't understand why not implement it if it gives such boost without drawbacks

…

On Fri, Aug 23, 2024, 01:22 Frederik Zipp ***@***.***> wrote: Also, duplicate of #47657 <#47657> — Reply to this email directly, view it on GitHub <#69027 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZCUDGQ34MDUYYXSY2ALXLZSZQBLAVCNFSM6AAAAABM66JSXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBVHA2DQMBYGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ianlancetaylor]

Because simply changing the code would not be backward compatible, and would break existing users. See issues #47657 and #48287.

[Gaudeamus]

Ok, sorry I made you think it's proposal to "simply change code"

…

On Fri, Aug 23, 2024, 01:41 Ian Lance Taylor ***@***.***> wrote: Because simply changing the code would not be backward compatible, and would break existing users. See issues #47657 <#47657> and #48287 <#48287>. — Reply to this email directly, view it on GitHub <#69027 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZCUDEF6SMQDQ65ESA4223ZSZSJPAVCNFSM6AAAAABM66JSXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBVHA3DONBSG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ianlancetaylor]

Apologies if I'm misunderstanding. In any case, as I said above, discussions should take place on a forum. Thanks.