fix(deps): update module github.com/puzpuzpuz/xsync to v4

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/puzpuzpuz/xsync	v1.5.2 -> v4.1.0

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

puzpuzpuz/xsync (github.com/puzpuzpuz/xsync)

v4.1.0

Compare Source

• New data structure: UMPSCQueue #​168
• Speed up LoadAndDelete and Delete in case of non-existing Map key #​167
• Parallel Map resize #​170

UMPSCQueue is meant to serve as a replacement for a channel. However, crucially, it has infinite capacity. This is a very bad idea in many cases as it means that it never exhibits backpressure. In other words, if nothing is consuming elements from the queue, it will eventually consume all available memory and crash the process. However, there are also cases where this is desired behavior as it means the queue will dynamically allocate more memory to store temporary bursts, allowing producers to never block while the consumer catches up.

From now on, Map spawns additional goroutines to speed up resizing the hash table. This can be disabled when creating a Map with the new WithSerialResize setting:

m := xsync.NewMap[int, int](xsync.WithSerialResize())
// resize will take place on the current goroutine only
for i := 0; i < 10000; i++ {
	m.Store(i, i)
}

Thanks @​PapaCharlie and @​llxisdsh for the contributions!

v4.0.0

Compare Source

• Minimal Golang version is now 1.24.
• All non-generic data structures are now removed. Generic versions should be used instead - they use the old names, but type aliases are present to simplify v3-to-v4 code migration.
• MapOf's hasher API is gone. The default and only hash function is now based on maphash.Comparable.
• Map's Compute API now supports no-op (cancel) compute operation.

Thanks @​PapaCharlie for making this release happen

Migration notes

• The old *Of types are kept as type aliases for the renamed data structures to simplify the migration, e.g. MapOf is an alias for Map.
• NewMapOfPresized function is gone. NewMap combined with WithPresize should be used instead.
• Map.Compute method now expects valueFn to return a ComputeOp value instead of a boolean flag. That's to support compute operation cancellation, so that the call does nothing.
• Map.LoadOrTryCompute method is renamed to LoadOrCompute. The old LoadOrCompute method is removed as it was redundant.

v3.5.1

Compare Source

• Clarify docs for LoadOrCompute and LoadOrTryCompute #​154

v3.5.0

Compare Source

• Add SPSCQueue/SPSCQueueOf #​152
• Add LoadOrTryCompute method to Map/MapOf #​153

Thanks @​mattjohnsonpint for suggesting the map enhancement.

v3.4.1

Compare Source

• Add ToPlainMap/ToPlainMapOf utility functions #​151

Thanks @​KiddoV for suggesting this enhancement.

v3.4.0

Compare Source

• Add optimistic locking methods to RBMutex #​138 and #​140
• Fix Map/MapOf capacity calculation for WithPresize #​139

RBMutex now has methods for optimistic locking:

mu := xsync.NewRBMutex()
if locked, t := mu.TryRLock(); locked {
	// critical reader section...
	mu.RUnlock(t)
}
if mu.TryLock() {
	// critical writer section...
	mu.Unlock()
}

Thanks @​kkroo for the contribution.

v3.3.1

Compare Source

• Add NewMapOfWithHasher function #​137

Adds NewMapOfWithHasher function to support custom hash functions in MapOf:

m := NewMapOfWithHasher[int, int](func(i int, _ uint64) uint64 {
	// Murmur3 finalizer. No DDOS protection as it does not support seed.
	h := uint64(i)
	h = (h ^ (h >> 33)) * 0xff51afd7ed558ccd
	h = (h ^ (h >> 33)) * 0xc4ceb9fe1a85ec53
	return h ^ (h >> 33)
})

Some custom hash functions may be faster than the built-in function if the lack of DDOS protection is fine.

Murmur3 finalizer:

BenchmarkMapOfInt_Murmur3Finalizer_WarmUp/reads=100%-8         	525864650	         2.240 ns/op	 446360938 ops/s	       0 B/op	       0 allocs/op
BenchmarkMapOfInt_Murmur3Finalizer_WarmUp/reads=99%-8          	383333918	         3.127 ns/op	 319827294 ops/s	       0 B/op	       0 allocs/op
BenchmarkMapOfInt_Murmur3Finalizer_WarmUp/reads=90%-8          	267635385	         4.535 ns/op	 220506863 ops/s	       0 B/op	       0 allocs/op
BenchmarkMapOfInt_Murmur3Finalizer_WarmUp/reads=75%-8          	181292007	         6.448 ns/op	 155092697 ops/s	       2 B/op	       0 allocs/op

Built-in hash function:

BenchmarkMapOfInt_WarmUp/reads=100%-8         	431097415	         2.858 ns/op	 349837551 ops/s	       0 B/op	       0 allocs/op
BenchmarkMapOfInt_WarmUp/reads=99%-8          	307244330	         3.951 ns/op	 253072903 ops/s	       0 B/op	       0 allocs/op
BenchmarkMapOfInt_WarmUp/reads=90%-8          	226392990	         5.306 ns/op	 188477583 ops/s	       0 B/op	       0 allocs/op
BenchmarkMapOfInt_WarmUp/reads=75%-8          	159236962	         7.513 ns/op	 133108546 ops/s	       2 B/op	       0 allocs/op

v3.3.0

Compare Source

• Speed up MapOf lookups #​134
• Expose Map/MapOf statistics #​133
• Change license to Apache License 2.0 #​135

Introduces meta memory and SWAR-based lookups similar to C++'s absl::flat_hash_map hash table (https://abseil.io/docs/cpp/guides/container). The lookups are now up to 30% faster.

Also, reduces MapOf's memory overhead: each bucket now holds up to 5 entries instead of 3.

Map/MapOf statistics are available via m.Stats(). They may be used for diagnostic purposes.

v3.2.0

Compare Source

• Introduce Map/MapOf configs and grow-only option (#​132)

Adds options support to the NewMap/NewMapOf functions. A MapOf can now be created like this:

m := xsync.NewMapOf[int, int](WithPresize(100))

NewPresizedMap/NewPresizedMapOf functions are deprecated. Use the WithPresize option instead.

Also, adds WithGrowOnly option. It configures new Map/MapOf instance to be grow-only. This means that the underlying hash table grows in capacity when new keys are added, but does not shrink when keys are deleted. The only exception to this rule is the Clear method which shrinks the hash table back to the initial capacity.

Grow-only maps are more efficient in the case of oscillating map size, i.e. when the map frequently grows and then shrinks in size.

v3.1.0

Compare Source

• Use presized Map/MapOf argument as the minimal map capacity (#​121)

NewMapPresized/NewMapOfPresized's argument is now treated as the minimal table capacity. The underlying hash table won't shrink beyond the specified capacity.

Also, fixes and improves godoc.

v3.0.2

Compare Source

• Fix too aggressive Map/MapOf shrinking on deletion leading to out of range panic (#​113)

Thanks @​mdumandag for reporting the issue.

v3.0.1

Compare Source

• Fix lost updates on concurrent Map/MapOf resize (#​111)

Thanks @​klauspost for reporting this issue.

v3.0.0

Compare Source

• Replace the user-defined hash function in MapOf factories with a built-in fast hash function (#​107, #​108)

All New*MapOf* functions are now replaced with the NewMapOf and NewMapOfPresized functions. There is no longer a need to provide a user-defined hash function.

Kudos go to @​destel

v2.5.1

Compare Source

• Speed up built-in string hash function (#​106)

v2.5.0

Compare Source

• Add concurrent queue with generics support (MPMCQueueOf) (#​104)

v2.4.1

Compare Source

• Fix nextPowOf2 on zero input (#​98)
  • Fixes the initial capacity of maps presized to a very small capacity (less than 3)

v2.4.0

Compare Source

• Add presized constructors for Map and MapOf (#​86)
• Fix potential iteration over duplicate keys in Map/MapOf.Range (#​87 and #​88)

v2.3.2

Compare Source

• Optimize MapOf.Range (#​82)
• Report throughput metric in benchmarks (#​81)
• Update benchmark results page (#​83)

Thanks @​felixge for holding a comprehensive (and lengthy) benchmarks run.

v2.3.1

Compare Source

• New MapOf design (#​78)
  • MapOf now takes full advantage of Go generics: less GC pressure, less atomic operations on reads, also improved integer hash function
  • If you're into benchmarking, comparisons with other concurrent map implementations are welcome (see this and this PRs as comparison examples)

v2.3.0

Compare Source

• Optimize MapOf integer hash function (#​76)
• Optimize RBMutex footprint and thread-to-slot distribution (#​75)
  • This is a breaking change. NewRBMutex() function must be called now to initialize a RBMutex.

v2.2.0

Compare Source

• Optimize Counter thread-to-stripe distribution (#​71 and #​74)
  • This is a breaking change. NewCounter() function must be called now to initialize a Counter.

v2.1.0

Compare Source

• Add Clear method to Map and MapOf (#​64)
• Add Compute method to Map (#​68 and #​69)
• Fix the second valueFn call in MapOf.LoadOrCompute (#​66)

Thanks @​psyhatter and @​veqryn for the contribution.

v2.0.2

Compare Source

• Fix duplicate keys on intensive map insertion and deletion (#​63)

v2.0.1

Compare Source

• Update version in package name (#​61)

v2.0.0

Compare Source

• Use hash/maphash instead of go:linkname hacks (#​56)
  • This changes the MapOf API in favor of the standard hash/maphash package. The main difference is in the hasher argument expected in the NewTypedMapOf function.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[coveralls]

coverage: 53.941%. remained the same
when pulling cc1c18f on renovate/github.com-puzpuzpuz-xsync-4.x
into 7c6142f on main.

[renovate]

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future 4.x releases. But if you manually upgrade to 4.x then Renovate will re-enable minor and patch updates automatically.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.