rr replay becomes slow on ARM64 (AWS c6g.4xlarge)

I'm on a Graviton instance. The rr replay works good on the exact same trace weeks ago. But without change rr itself and gdb, today I open the rr replay on the same trace. It becomes very slow when it replay after I run "continue" and it is unusable in my case. I did the profiling, 99% time is spent in the following call stack. How can I fix it?

My environment is c6g.4xlarge AWS Graviton instance. Kernel is 6.2.0-1011-aws https://github.com/rr-debugger/rr/pull/11~22.04.1-Ubuntu. GDB 13.2. rr version 5.6.0.

_start
__libc_start_main_impl (inlined)
__libc_start_call_main
main
gdb_main
captured_command_loop
gdb_do_one_event
gdb_wait_for_event
run_async_handler_and_reschedule
fetch_inferior_event
handle_inferior_event
handle_stop_requested (inlined)
handle_signal_stop
skip_inline_frames
block_for_pc
block_for_pc_sect (inlined)
blockvector_for_pc_sect (inlined)
find_pc_sect_compunit_symtab
lookup_minimal_symbol_by_pc_section
find_pc_section
update_section_map (inlined)
std::sort<obj_section**, bool (*)(obj_section const*, obj_section const*)> (inlined)
std::__sort<obj_section**, __gnu_cxx::__ops::_Iter_comp_iter<bool (*)(obj_section const*, obj_section const*)> > (inlined)
sort_cmp

Start by reproducing rr replay on the reported ARM64 AWS Graviton environment with the same trace, then inspect the profiled GDB path from handle_signal_stop through block_for_pc and update_section_map. Compare replay behavior and profiling with the stated rr 5.6.0, GDB 13.2, and kernel versions; done requires identifying and resolving the cause of the severe slowdown.