> There are three objections to the new model:
> 1. The new model abandons Leo's underlying DAG.
> The new model duplicates cloned nodes. Cloning a node can be arbitrarily 
> expensive in terms of space.
> This is just your guess not supported by any real measurement. All 
duplicated data is either primitive data type like int, float, byte or it 
is a string or list of strings. Cost of duplicating strings  in Python is 
just a size of a pointer (8 bytes), cost of duplicating list with 10 
elements is about 10-12 pointers. So, even if it seems like a lot of 
duplicated data it is not worth considering as a problem in a computer with 
4G RAM.  I suggest that you make some experiments to see for yourself. For 
example take the LeoPyRef.leo into new model and make a 1000 copies and see 
if you can notice any sign of the GC activity.

2. The new model will not, in fact, be faster than Leo's existing code.
> Any claimed speed improvements come from faster redraw.  Leo's fundamental 
> tree operations are simpler and faster than in the new mode.  Leo's 
> redrawing could be made *much *faster than at present, without changing 
> Leo's data model.
> That is also wrong, I made clear comparison and almost all traversals are 
faster in the new model, and traversals are by far most frequent operations 
done on outline.

3. The new model is substantially more complex than Leo's data and code.
> While VNode class is extremely simple, Position is somewhat more complex 
then VNode but both of them together are simpler than the new data model. 
However, because of this simplicity of VNode and Position, complexity 
arises everywhere else. Selecting a position is extremely complex. Find and 
replace operation extremely complex. Redrawing extremely complex. Undo/redo 
extremely complex, copy/paste extremely complex. On the other hand new data 
model contains complexity in only one place, inside new data model. Longer 
method bodies doesn't mean same as being complex.  There is nothing complex 
there. Some basic list operations and integer arithmetic. If you look 
carefully in the promote method that you used as an example you will see 
that it calls only three helper methods which are short functions 
*update_size* (6 lines) and *up_level_index* (3 lines) and *gnx_iter* (9 
lines). So, total length of *promote* is 98 + 6 + 3 + 9 = 116 lines 
including empty lines and comments. However, you have compared wrong 
methods. What you have named promote I have named promote_children and what 
is promote in new data model you have named demote (which doesn't exist in 
Position or VNode). I have realized this difference while writing scripts 
that compare the speed between the two. I thought that promoting a node 
means that it become parent of following siblings, while you had in mind 
lowering its level as a promotion. Anyway, in 116 lines it is implemented a 
command that can be directly wired to some GUI shortcut or used in a script 
to change the outline. If you compare this with all the code that Leo has 
to execute to perform this operation you would find more than 116 lines 
even if the implementation of this method on Position class is shorter. 

Each objection is sufficient to reject the proposal. I shall do so unless I 
> can be persuaded that I have misunderstood something crucial.
> I hope you will reconsider this again. 

You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to