Re: [ jEdit-devel ] How to cap memory usage on massive replace-all

[Kazutoshi S. <k_s...@f2...>]

Thomas Meyer wrote:
> Am 20.06.2012 um 18:10 schrieb Kazutoshi Satoda:
>> Thomas Meyer wrote:
>>> Am Samstag, den 09.06.2012, 18:45 +0900 schrieb Kazutoshi Satoda:
>>>> Thomas Meyer wrote:
>>>>> I worked on something on top of #3531515. The idea is when the number of
>>>>> objects in the CompoundEdit gets too large, then we do create a copy of
>>>>> the buffer's content and use this as undo content.
(snip)
>> I still don't understand how the new idea is preferred. I can see only
>> some cons as I shown above.
>
> I thought that this would be the easier way of implementing this.
>
> I don't know how the compaction of n Replace into 1 Replace should work.

We need a way and condition for "Adjacent 2 Replace -> 1 Replace".
"n Replace into 1" can be achieved by repeated application of the
adjacent case.

If you don't know how to implement the adjacent case, could you please
give a specific question?

> maybe the real problem is the storage of undo/redo Edit as linked-list.

Even if it got lowered down to 10 byte per Edit (1/4 of the current
situation), the total memory usage will be still too large.

I'm seeing the real problem as the O(N) memory usage where N is the
number of occurrences of search&replace. The folding is a solution which
caps the memory usage to the size of buffer contents * 2 or so.


P.S.
To eliminate mgr field in Edit, I think it's suitable and
straightforward to change the field into a parameter of Edit.undo()/
redo() method.

-- 
k_satoda