enhance #10 : avoid allocations on parseUUID

[ashwingopalsamy]

Changes

With this PR, we rewrite parseUUID to process input directly, avoiding unnecessary string allocations when handling UUIDs with -. The function now uses a pre-allocated byte slice and skips dashes inline to improve its efficiency, with few additional checks.

This should address the issue raised in #10. Let me know your thoughts! @vtolstov

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Flag	Coverage Δ
unittests	90.67% <100.00%> (+0.72%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
helper.go	100.00% <100.00%> (ø)

[ccoVeille]

Suggested change

	if len(uuid) == 32 {
	// Fast path for UUIDs without dashes
	return hex.DecodeString(uuid)
	} else if len(uuid) == 36 {
	// Validate dash positions
	if uuid[8] != '-' || uuid[13] != '-' || uuid[18] != '-' || uuid[23] != '-' {
	return nil, errors.New("invalid UUID format")
	}
	} else {
	return nil, errors.New("invalid UUID length")
	}
	switch len(uuid) {
	case 32:
	// Fast path for UUIDs without dashes
	return hex.DecodeString(uuid)
	case 36:
	// Validate dash positions
	if uuid[8] != '-' || uuid[13] != '-' || uuid[18] != '-' || uuid[23] != '-' {
	return nil, errors.New("invalid UUID format")
	}
	default:
	return nil, errors.New("invalid UUID length")
	}

[ccoVeille]

Also, if you consider this

#12 (comment)

Suggested change

	if len(uuid) == 32 {
	// Fast path for UUIDs without dashes
	return hex.DecodeString(uuid)
	} else if len(uuid) == 36 {
	// Validate dash positions
	if uuid[8] != '-' || uuid[13] != '-' || uuid[18] != '-' || uuid[23] != '-' {
	return nil, errors.New("invalid UUID format")
	}
	} else {
	return nil, errors.New("invalid UUID length")
	}
	switch len(uuid) {
	case 32:
	// Fast path for UUIDs without dashes
	return hex.DecodeString(uuid)
	case 36:
	// Validate dash positions
	if uuid[8] != '-' || uuid[13] != '-' || uuid[18] != '-' || uuid[23] != '-' {
	return nil, errors.New("invalid UUID format")
	}
	return hex.DecodeString(strings.ReplaceAll(uuid, "-", ""))
	default:
	return nil, errors.New("invalid UUID length")
	}

[ccoVeille]

Or this

Suggested change

	if len(uuid) == 32 {
	// Fast path for UUIDs without dashes
	return hex.DecodeString(uuid)
	} else if len(uuid) == 36 {
	// Validate dash positions
	if uuid[8] != '-' || uuid[13] != '-' || uuid[18] != '-' || uuid[23] != '-' {
	return nil, errors.New("invalid UUID format")
	}
	} else {
	return nil, errors.New("invalid UUID length")
	}
	if len(uuid) == 36 {
	// Validate dash positions
	if uuid[8] != '-' || uuid[13] != '-' || uuid[18] != '-' || uuid[23] != '-' {
	return nil, errors.New("invalid UUID format")
	}
	uid = strings.ReplaceAll(uid, "-", "")
	}
	if len(uuid) != 32 {
	return nil, errors.New("invalid UUID length")
	}
	// Fast path for UUIDs without dashes
	return hex.DecodeString(uuid)

[ccoVeille]

Why not a simple strings.ReplaceAll?

[ashwingopalsamy]

Good point! Primary reason was to address #10 . When I attempted 'Benchmarking', the current implementation was faster and avoids memory allocations.

Here are the benchmark results comparing the two:

Implementation	Time per Operation (ns/op)	Speed
strings.ReplaceAll()	146.2 ns/op	Baseline
Current Approach	68.17 ns/op	2.22x faster

How?

This approach processes the UUID in one pass, directly copying characters into a pre-allocated byte slice. This avoids creating a new string, which is what strings.ReplaceAll does and keeps things lean.

[ccoVeille]

Please add:

• a valid uid with the dashes at the right place
• an invalid uid with the dash at the right place plus one randomly placed,or simply 36 dashes

[ashwingopalsamy]

Sure thing! Added in the latest commit.

[vtolstov]

is this changes in some parts goes to google/uuid repo pr ?

[ashwingopalsamy]

Let me see what I can do best there. I had the flexibility of writing this repo in my preferred style and structure.

With google/uuid, I had to follow what was already in-place..

[ashwingopalsamy]

Sadly, people aren't reviewing the proposal there. It'd be great if the PR gets some attention.