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 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.