Term additions no longer copy into the C heap
AddTerm is the one call an indexer makes per token, and C.CString made each one cost three crossings into C — malloc, the call, free — where one is needed. The shim now takes a pointer and a length, and the Go side hands over the string's own bytes.
Measured against a real Xapian database (512 terms per document, Go 1.26, xapian-core 2.0.0):
| ns/term | |
|---|---|
| before | 254.8 |
| after | 201.8 |
| −21% |
The 53 ns saved matches a standalone measurement of the allocation pair to within 3%. Of what remains, roughly 185 ns is Xapian indexing the term and 16.5 ns is the crossing — so this is most of what a binding can remove without changing the API.
Terms are bytes, on both sides
QueryTerm takes the same shape, and not for speed. Converting only the write path meant a term containing a NUL was indexed whole and then never found, because the query truncated it. Both paths now agree on what a term is.
Safety
Xapian's add_term takes const std::string & and stores a copy; the pointer is not retained past the call, which is what makes passing Go memory legal here. TestTermsSurviveTheStringsTheyCameFrom asserts the consequence rather than the claim — source strings are dropped and the heap churned before the terms are read back, because a retained pointer would return garbage rather than fail. Tests pass under GOEXPERIMENT=cgocheck2 and -race.
Breaking, at the C level only
fcx_doc_add_term, fcx_doc_add_boolean_term and fcx_query_term now take an explicit length. The Go API is unchanged — no caller of this module needs edits beyond the version bump.
Full diff: v0.1.0...v0.2.0