format: allocation regression tests

Open Beginner friendly
#46 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
go
Domain
performance, testing

Research direction

Start with format/zeroalloc_test.go and inspect the existing equivalence tests for DecodeXRowInto, EncodeXRow with a reused buffer, the DecodeBodyInto paths from #38, and DecodeOpsInto from #44. Extend those tests with exact zero-allocation assertions, keeping them off the -short path if needed; done means the required paths fail when allocations become nonzero.

Written by the indexing model from the issue text.

Description

code health

The zero-allocation property is currently a fact about the code, not a guaranteed one. DecodeXRowInto and EncodeXRow measure 0 allocs/op today; nothing fails if a future change adds one. Given that a whole consumer is about to be built on this property, it should be enforced.

Add testing.AllocsPerRun assertions for the paths that must stay at zero:

  • DecodeXRowInto
  • EncodeXRow into a reused buffer
  • each Decode<X>BodyInto from #38
  • DecodeOpsInto from #44

Baselines measured at 82bf1df (Apple M4 Pro):

path ns/op B/op allocs
DecodeXRowInto 60 0 0
EncodeXRow (reused buf) 15 0 0
+ DecodeDMLBody, clean INSERT 131 144 1
+ DecodeDMLBody, body with INDEX_ID 207 480 3

The last two rows are what #38 and #39 are expected to drive to zero; this issue is what keeps them there.

Note format/zeroalloc_test.go already exists but tests equivalence between the allocating and non-allocating forms, not the allocation count itself. This extends it rather than replacing it.

Suggested guard: assert == 0 exactly, not a threshold — a threshold hides the regression that matters. Keep the assertions off the -short path if they prove flaky under -race (allocation counts differ under the race detector).

Dominant language
Go
Stars
0
Forks
0
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tarantool/go-xlog

All issues in tarantool/go-xlog

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.