> 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
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.