chore: avoid redundant IndexDocument construction in heap emplace

[longway-code]

Summary

IndexDocumentHeap::emplace now checks score < front().score() before calling into ailego::Heap, avoiding unnecessary object construction for candidates that would be rejected anyway.

Performance

Tested locally, decreased ~15% end-to-end latency of FlatSearcher::search_impl (N=100k, dim=128, topk=10, FP32 SquaredEuclidean, 200 queries averaged).

All Tests Passsed

[iaojnh]

@greptile

[greptile-apps]

Greptile Summary

Optimizes IndexDocumentHeap::emplace by checking if a candidate would be rejected before constructing the IndexDocument object. The implementation adds a guard condition (!this->full() || score < this->front().score()) that mirrors the internal logic of ailego::Heap::emplace, preventing unnecessary object construction when:

• The heap is full AND
• The new score is not better than the current worst score

This optimization is semantically equivalent to the original implementation but avoids constructing IndexDocument objects that would be immediately discarded, achieving the reported ~15% latency improvement in search operations.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The optimization is a well-contained change that adds an early-rejection check mirroring the existing heap logic. The implementation correctly handles all edge cases (empty heap, not-full heap, full heap) through proper short-circuit evaluation, and the reported 15% performance improvement demonstrates measurable benefit with no functional changes to the algorithm
• No files require special attention

Important Files Changed

Filename	Overview
src/include/zvec/core/framework/index_document.h	Added early rejection check in IndexDocumentHeap::emplace to avoid constructing IndexDocument objects that would be rejected by the heap

_{Last reviewed commit: fe83ee8}

[richyreachy]

hi @longway-code, thanks for your kindly contribution.

As we see the fix, the condition to avoid emplace, is quite same as the emplace inner logical condition.

We'll take a test to see if this can bring the mentioned performance improvement.

[richyreachy]

Hi, @longway-code, a test we took by @iaojnh shows there's no remarkable improvement over current codes. Could you please provide more details about the test setup and datasets etc. ?