On Thursday, May 17, 2018 at 9:20:33 PM UTC+2, Matt Wilkie wrote:
>
> I have just published first two articles about what I have done so far in
>> this mini-project. Here are the links:
>>
> [...]
>
>> All comments are welcome.
>>
>
> Vitalije, I'm working my through your posts on that site from the
> beginning. It's slow because I understand little because of my shallow
> coding background. However I want to say that enjoy them and learn things.
> Top of mind at the moment is your recognition that your initial attempts to
> communicate an idea didn't work and that a) building a demo might be
> effective, and b) choosing something that wasn't currently in discussion
> but had been before would invite deeper inspection and involvement.
>
> Thanks,
>
> Matt
>
Matt Wilkie, thanks for these kind comments. I am glad you like it.
I have almost finished small gui that uses new LeoTreeModel as its data
model. Reading and writing external files works correctly. I have made
methods for all tree operations that I could think of. Promote/Demote, move
node up, down, left and right, move node to any given position. Now here
are some comparisons with the present Leo:
A node with the following body:
import timeit
def f():
c.demote()
c.promote()
def test(fun, num):
t1 = timeit.timeit(fun, number=num)/num*1000
g.es('%s avg:%.1fms'%(fun.__name__, t1))
def f2():
c.moveOutlineDown()
c.moveOutlineUp()
test(f, 10)
test(f2, 10)
Make it last node in outline, then make a clone of it, and insert three
empty nodes after with heading a,b and c.
Let those five nodes be the last five top-level children of the outline.
Select second clone (one closer to the end) and execute script.
The results depend on the size of the visible outline. I have tried with
the LeoPy.leo and at first with all nodes collapsed I've got the following
results:
f avg:126.6ms
f2 avg:160.9ms
When similar script executed on the same nodes in my gui prototype:
demote/promote average: 3.3ms
up/down average: 3.8ms
Here is the script:
def speedtest(x):
import timeit
pos = ltm.positions[-4]
def f1():
ltm.promote(pos)
draw_tree(tree, ltm)
ltm.promote_children(pos)
draw_tree(tree, ltm)
def f2():
ltm.move_node_down(pos)
draw_tree(tree, ltm)
ltm.move_node_up(pos)
draw_tree(tree, ltm)
t1 = timeit.timeit(f1, number=100)/100*1000
t2 = timeit.timeit(f2, number=100)/100*1000
print('demote/promote average: %.1fms\n'%t1)
print('up/down average: %.1fms\n'%t2)
Just executing once expand-all took too much time (didn't measure but more
than 20s). After that I have reduced the number of timeit executions to
just 1 and got the following results (with fully expanded tree of LeoPy.leo)
f avg:4374.2ms
f2 avg:4385.8ms
Performing same in prototype gui, expanding all nodes was instantaneous and
timing it 100 times gave me the following results:
demote/promote average: 16.4ms
up/down average: 19.3ms
As you can see it is definitely dependent on the number of visible nodes,
but nevertheless it is much faster than current Leo implementation.
To be fair, I must point out that Leo is performing also undo/redo logic
which my prototype still doesn't. But taking a full snapshot of the tree in
the new model was measured before and it used to take about 20ms, for the
outline of about 8300 nodes (LeoPyRef.leo).
With that snapshot time added new model is still at least 100 times faster
than Leo in the worst case (for Leo) and about 6 times faster in the
easiest case for Leo (with all nodes collapsed).
Even if the changing Leo tree is O(1) operation, it seems that overall
operation is much worse. Increasing number of visible nodes from 28 to 8349
(about 300 times more), caused time to grow from 0.1s to 4s or about 40
times. This of course is not real proof, but for practical purposes will
do. New model OTOH slows down by factor of 6 when increasing number of
visible nodes 300 times.
What still remains to be done in my prototype is importing files, reading
at-auto files which is wide area considering how many different languages
Leo supports. I will try to make python, markdown and rest importers next
because they are used in Leo, Leo's installation folder have files that I
can use for the testing and comparing with the Leo importers.
For the javascript importer I have an idea to use node modules for parsing
numerous javascript dialects. Existing node modules like babel have already
solved the problem of different dialects and can produce necessary data for
Leo to create well shaped outline. And those node modules work very fast.
They analyze hundreds of js files in less than 10s.
And it is most likely that every user who wants to use Leo for editing
javascript, has already installed node.
Vitalije.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this
