Eli Zaretskii writes: >> 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? "fast" (emacs 28) session does not have this call tree contributing significantly. > 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? We only established that the number of markers cannot be the problem. However, buf_bytepos_to_charpos still dominates CPU samples (see the attached) in Emacs master, but not in Emacs 28. Unless there is some other place in buf_bytepos_to_charpos that may be slow, the only possible explanation is that it simply gets called more times. Then, we are interested in the callers of buf_bytepos_to_charpos. That's exactly what I provided in the previous message. >> 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. re_match_2_internal calls SYNTAX_TABLE_BYTE_TO_CHAR in a loop. So, if something strange is happening with the loop, we may be calling buf_bytepos_to_charpos more.