> From: Stefan Monnier <monn...@iro.umontreal.ca> > Cc: rpl...@gmail.com, 23...@debbugs.gnu.org, alex.ben...@linaro.org, > jwieg...@gmail.com, nljlistb...@gmail.com > Date: Tue, 19 Jul 2016 21:50:07 -0400 > > > Do we care that using save-match-data in every call to replace-match > > might mean a performance hit? > > I do but: > - to be honest, it's probably lost in the noise. > - if we copy search_regs.start and search_regs.end with something like > alloca+memcpy (instead of calling Fmatch_data), the cost should be even more > lost in the noise. Especially if you consider that the current code > already loops through the match-data to adjust it. > - it's the best fix we've found so far.
What about Noam's suggestion: > Is it not possible to adjust the match data *before* calling buffer > modification hooks? Seems to me the root of the problem is that buffer > modification hooks get to see this invalid intermediate state where the > match data is out of sync with the buffer. Is it OK to adjust the match data before actually making the replacement? If so, I think it's a simpler solution. > PS: I can think of one (theoretical) other/better way to fix this > problem: move the match-data adjustment so it's done within > replace_range before running the after-change-functions. Isn't that almost the same as what Noam suggested?
