GNU bug report logs -
#58558
29.0.50; re-search-forward is slow in some buffers
Previous Next
Full log
Message #158 received at 58558 <at> debbugs.gnu.org (full text, mbox):
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: monnier <at> iro.umontreal.ca, larsi <at> gnus.org, 58558 <at> debbugs.gnu.org
> Date: Sun, 09 Apr 2023 19:54:49 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I think we should first go back to using perf. I don't think you
> > compared profiles for Emacs which just started with one that was
> > running long enough to show the slowdown. Comparing such profiles
> > should at least give us a hint where to look.
>
> I now tried perf record -g.
> I was able to narrow down the call tree of the problematic
> buf_bytepos_to_charpos calls:
>
> 43.82%--Fre_search_forward
> --43.81%--search_command
> --43.78%--search_buffer
> --43.78%--search_buffer_re
> --43.33%--re_search_2
> --36.39%--re_match_2_internal
> --21.90%--SYNTAX_TABLE_BYTE_TO_CHAR
> --21.57%--BYTE_TO_CHAR
> --21.49%--buf_bytepos_to_charpos
>
> Not sure if it is telling much.
How does this compare with a "fast" session doing the same?
And why are you once again focusing on buf_bytepos_to_charpos, when
you previously (presumably) established that it cannot be the problem,
since the number of markers doesn't change significantly?
> I also looked into git history and I can only identify significant
> changes in re_match_2_internal after Emacs 28 release.
It sounds like most of the time is not in re_match_2_internal itself.
But I think comparison with a "fast" session could help with ideas.
Thanks.
This bug report was last modified 2 years and 64 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.