Mass replace is slower by 6sec each time

[Alexey-T]

Maybe related to #5489 .

• I open bug5473.txt bug5473.txt
• mass replace 'a' to 'b' without RegEx -> takes 2s
• w/o restarting, mass replace 'b' to 'c'-> takes 6s
• now 'c' to 'd' -> takes 12s
• again -> takes 19s
• again -> takes 27s

Maybe Undo data is slowing it. HiOccur plugin is active with "sel_allow":true.

[pintassilgo]

Good catch, but just saying this is a different issue from #5489 because there's no undo data for bug5473.txt in my Cuda. It's exactly the same as its identical copy, with the only difference being filename. Yet one is fast to find and the other is slow.

I even said in that issue it's still reproducible after deleting history* files.

[Alexey-T]

Console testing of PROP_UNDO_DATA shows undo is increasing each time

>>> len(ed.get_prop(PROP_UNDO_DATA,''))
19
>>> len(ed.get_prop(PROP_UNDO_DATA,''))
5220912
>>> len(ed.get_prop(PROP_UNDO_DATA,''))
10441805

[Alexey-T]

Guess it is not fixable, it is memory reallocs in Undo list; which are slower when list is increasing.

[pintassilgo]

Guess it is not fixable, it is memory reallocs in Undo list; which are slower when list is increasing.

But should this affect replace speed? I guess no. Replacing the same content should take the same time no matter file name (#5489), undo history (this #5490)... Just get content as a string, replace then put the final string in editor. Undo history, file name and other things shouldn't affect replacing.

[Alexey-T]

Each replacing of each 'a' char - makes new item in the Undo list. Total mass replace makes lot of new items, so undo list size increases by 5 Mb.

[pintassilgo]

Yes, but I don't see a reason for the time to be cumulative.

If mass replace takes 2s, accepting that replacing increases Undo list, further similar replaces should take near the same time (2s).

Taking like 2 + (replace run number) * 5 sounds as a bug, as if under the hood it's redoing all previous replaces again and again.

Replacing a to b and appending to undo history should be the same as replacing b to c and appending to undo history.

It looks current Cuda recalcs entire Undo history instead of just inserting new undos after last replace.

[Alexey-T]

It looks current Cuda recalcs entire Undo history instead of just inserting new undos after last replace.

no, it reallocates undo list.

• first replace: undo list was 0b -> realloc to 5Mb takes ~1s
• 2nd replace: undo list was 5Mb -> realloc from 5Mb to 10Mb takes more time

this is my guess.

[pintassilgo]

Let's assume replacing takes 2s, because that's the time for the first run. Do you think it's correct for realloc from 20Mb to 25Mb to take 27 seconds? It clearly looks a bug of inefficient implementation.

[Alexey-T]

right. debugging shows the reason. adding of Undo items saves 860 color-attribs per each undo-item. attribs with tag=101. it is HiOccur plug! fixed now.

[Alexey-T]

try the new beta. test it also with HiOccur-related slowdown issue.

[pintassilgo]

Thanks. I confirm this one is fixed.