Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Investigate slow array-backed object access in jperl

未关闭
#1,854 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
38/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
java, perl
领域
performance

调研方向

Start with dev/bench/benchmark_method.pl and run the hash-backed and array-backed variants in fresh PerlOnJava processes, as described. Then profile the method-call workload and trace generated JVM code and runtime helpers for field reads and updates; compare JVM and interpreter backends. Done means the performance gap is localized, with a focused benchmark or regression check added and an optimization that preserves Perl semantics.

由索引模型根据 Issue 内容生成。

描述

Summary

Investigate why array-backed objects are substantially slower than hash-backed objects in PerlOnJava for repeated method calls and field updates. The same benchmark shows a small array advantage in system Perl, so this appears to be a PerlOnJava implementation-path difference rather than an inherent cost of Perl array objects.

Reproduction

Run dev/bench/benchmark_method.pl, which performs 500 Benchmark iterations of a method called 20,000 times per iteration. Foo::add reads and increments $self->{x} and $self->{y}, then returns their sum.

For the array-backed variant, replace construction with bless [ 1, 2 ], $class, and change the field accesses to $self->[0] and $self->[1].

Both variants completed successfully and printed the same final value: done 399600080000.

Observed performance

Reported by Perl's Benchmark::timethis (iterations/second; larger is faster):

Runtime Hash-backed Array-backed Difference
System Perl 329–330/s 359–360/s array ~9% faster
PerlOnJava (jperl) 264–268/s 89–91/s array ~66% slower

The PerlOnJava result was repeated twice after the initial run and was consistent. Each PerlOnJava run was executed in a fresh process.

Investigation goals

  • Profile the benchmark to separate method dispatch, argument setup, scalar arithmetic, hash access, and array access costs.
  • Trace generated JVM code and runtime helpers for $self->{key} versus $self->[index], including lvalue fetch/store paths.
  • Determine whether array access allocates or copies wrappers, performs redundant bounds/type checks, or takes a slower generic path.
  • Compare JVM and interpreter backends to localize the issue.
  • Add a focused benchmark or regression performance check once the hot path is understood, then optimize without changing Perl semantics.

Caveats

This is a microbenchmark of the complete method-call path, not an isolated container benchmark. The result does not prove hash access is optimal; it shows that this workload currently favors hash-backed objects in PerlOnJava. More controlled access-only benchmarks and profiling are needed before attributing the gap to a specific implementation component.

主要语言
Perl
星标
64
派生
8
平均合并
5 小时 44 分钟
30 天内合并 PR
203

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

fglock/PerlOnJava 的其他 Issue

查看 fglock/PerlOnJava 的全部 Issue

相似的 Issue

更多 Perl Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。