Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Investigate slow array-backed object access in jperl

Aberta
  • Algo errado?
#1,854 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
38/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
java, perl
Domínio
performance

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Perl
Estrelas
64
Forks
8
Merge médio
5h 42min
PRs com merge (30d)
205

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de fglock/PerlOnJava

Todas as issues de fglock/PerlOnJava

Issues semelhantes

Mais issues de Perl

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.