Add a minimal micro-benchmark suite to validate filtering hot-path optimizations
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- cpp
- Lĩnh vực
- build-system, performance, tooling
Hướng nghiên cứu
Bắt đầu bằng cách xem xét thiết lập CMake và GoogleTest hiện có, sau đó lần theo đường dẫn filtering bên dưới src/iceberg/**/ và các metrics evaluators của nó. Công việc hoàn tất khi dự án có một benchmark suite tối thiểu đã được thống nhất, một tùy chọn build bị tắt theo mặc định và một benchmark đo riêng bước filtering.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
While reading the scan-planning filtering path, I found a small optimization in the metrics evaluators. Using it as a concrete example to raise a broader question about how to validate this kind of change.
Proposed change
The metrics evaluators run per data file. Each predicate currently calls expr->reference() repeatedly, and reference() returns a shared_ptr via shared_from_this() — an atomic refcount bump every time. The StrictMetricsEvaluator macro even discards a dynamic_cast result only to re-fetch the same reference:
- #define RETURN_IF_NOT_REFERENCE(expr) \
- if (auto ref = dynamic_cast<BoundReference*>(expr.get()); ref == nullptr) { \
- return kRowsMightNotMatch; \
- }
+ #define BIND_REFERENCE_OR_RETURN(ref, expr) \
+ const auto* ref = dynamic_cast<const BoundReference*>((expr).get()); \
+ if (ref == nullptr) { \
+ return kRowsMightNotMatch; \
+ }
Result<bool> IsNull(const std::shared_ptr<Bound>& expr) override {
- RETURN_IF_NOT_REFERENCE(expr);
- int32_t id = expr->reference()->field().field_id();
+ BIND_REFERENCE_OR_RETURN(ref, expr);
+ int32_t id = ref->field().field_id();
...
Reusing the cast result drops the repeated virtual reference() calls (and their atomic ops) across every predicate, with no behavior change.
Expected benefit
The win is on the CPU-bound filtering step, evaluated in isolation. Scan planning as a whole is IO-bound, so on an e2e scan this kind of change is almost certainly unmeasurable — which is exactly why it needs to be measured on the filtering step alone.
Which raises the question: do we need a benchmark suite?
This is exactly the kind of change that's hard to justify without one. The repo has no benchmark infrastructure today, only the gtest suite. A minimal benchmark on the filtering path would let us measure such changes on the CPU-bound step alone, rather than guessing or claiming a win against IO-dominated planning.
So before going further:
- How should we add it — Google Benchmark fetched the same way googletest already is, behind an off-by-default CMake option?
- Where should it live — a top-level
benchmark/, or co-located undersrc/iceberg/**/?
I'm happy to put up a draft PR for a minimal suite + the filtering benchmark above once there's agreement on direction.
- Ngôn ngữ chính
- C++
- Star
- 223
- Fork
- 127
- Merge trung bình
- 1 ngày 13 giờ
- Pull request đã merge (30 ngày)
- 28
Chuẩn bị môi trường
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của apache/iceberg-cpp
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
apache/iceberg-cpp#973 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 20/100
apache/iceberg-cpp#959 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Release Apache Iceberg C++ 0.4.0Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
apache/iceberg-cpp#955 · 3 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
apache/iceberg-cpp#946 · 5 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
apache/iceberg-cpp#944 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của apache/iceberg-cpp
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
cp-algorithms/cp-algorithms#1715 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Icinga/icinga2#11058 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
status:needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
PX4/PX4-Autopilot#28924 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
component: split-view platform: windows
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
zen-browser/desktop#15616 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày