Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Task] Establish systematic performance baselines and optimization tracking

Đang mở
  • Có gì không ổn?
#3,346 2 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@contrueCT đang làm issue này rồi.

Từ ngày 16/10/2026.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
12/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
databases, performance

Hướng nghiên cứu

This is a long-running tracking task, not a single change. Start with the linked Server PR #3342, which fixes lost Kout results, and its measurement review, to see which benchmark setup it used. The first concrete step would be a reproducible, correctness-checked Kout baseline with recorded commands, data generation, and environment details. Done means that baseline exists and candidate optimizations are ranked against it, not that any optimization is merged.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

help wanted improvement rust

Goal

Track long-term, evidence-driven performance work across HugeGraph traversal and its shared execution/collection paths. Start with Kout as a reproducible case, then extend to other representative operations when measurements reveal shared bottlenecks.

Optimize end-to-end efficiency under realistic workloads, rather than greedily improving one method, microbenchmark, or configuration at the expense of correctness, memory, latency, or concurrent throughput.

Starting evidence

🔗 Server #3342 fixes lost Kout results by serializing shared result-set updates and distinct-limit admission. Preserve this correctness guarantee. (Other cases like)

Bounded measurements and limitations show workload-dependent trade-offs between internal parallelism and concurrent requests. They do not establish a production regression caused by the fix, isolate monitor cost, or establish production-wide performance acceptance. No narrowed-lock optimization has been benchmarked.

This is a long-term task, not an additional 1.8 release gate. Candidate optimizations below are hypotheses to evaluate, not commitments to implement.

TODO

  • Establish a reusable, correctness-checked baseline and retain reproducible commands, data generation, raw results, environment details, and exact tested revisions.
  • Profile representative end-to-end workloads before prioritizing changes.
  • Rank opportunities by measured user impact, resource cost, implementation risk, and maintenance burden.
  • Implement justified optimizations separately, with before/after comparisons against a correct baseline.
  • Add stable regression coverage and document deployment/concurrency trade-offs.
  • Expand coverage to related traversals and shared infrastructure as evidence warrants.
Candidate investigations
  • Internal worker counts, executor reuse/admission, and resource budgets across concurrent requests.
  • Bounded/lazy edge-query and iterator preparation to avoid unnecessary work after limits are satisfied.
  • Primitive IdSet bulk union to reduce numeric-ID wrapping during layer merges.
  • Empty-frontier termination and avoidable allocation/cancellation overhead.
  • Critical-section scope or aggregation strategies only where profiling justifies them; preserve exact distinct limits, deduplication, visibility, resource cleanup, and off-heap ID safety.

Measurement and acceptance

  • Cover single and concurrent requests; several worker settings including the actual default; numeric/string IDs; unique/duplicate/convergent graphs; finite/unlimited limits; nearest modes; and representative graph sizes.
  • Include relevant backends and full API/service paths, not only isolated consumers. Distinguish warmed caches from genuinely cold storage.
  • Record throughput, latency distributions, CPU, allocation/GC, memory, and lock/scheduling observations. Use sufficient independent runs, warm-up, sustained durations, and variability reporting; short repeated samples are not independent experiments or production tail-latency proof.
  • Verify complete results where deterministic, exact counts and legal results for bounded queries, plus cancellation, capacity and resource-lifecycle behavior.
  • Agree workload-specific acceptance budgets before claiming success. Check for displaced costs and regressions in other supported workloads.
  • Change one causal factor at a time where practical. Report inconclusive results honestly; do not use unsafe old concurrent behavior as a performance target.

Keep findings and follow-up PRs linked here so improvements accumulate into a coherent performance baseline rather than isolated tuning.

Ngôn ngữ chính
Java
Star
3.2k
Fork
640
Merge trung bình
1 ngày 10 giờ
Pull request đã merge (30 ngày)
89

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/hugegraph

Tất cả issue của apache/hugegraph

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.