On Saturday, February 1, 2014 8:50:26 AM UTC-5, Edward K. Ream wrote:

> Yesterday I became quite concerned about the speed of the new @auto 
code...vc.compute_all_organized_positions [is] obviously the culprit.  Imo, 
it should be possible to make this code run in 0.1 sec. or less.  That's 
next. 

As of rev 6628, vc.compute_all_organized_positions takes 0.02 sec instead 
of 5+ seconds , a speedup of more than 200x. All the new code is in 
vc.find_position_for_relative_unl.  The speedup depends on caching the 
headlines of the children of nodes in vc.headlines_dict. This saves a 
stupendous amount of stepping through the outline.  One caveat: we must 
clear this dict after moving nodes!

> Imo, vc.move_nodes should be able to run in 0.1 sec. or less...I have 
some ideas about how to work around this problem, but this is not urgent 
just now.

I spent several hours thinking of ways to improve vc.move_nodes and its 
helpers.  The present code does a lot of unnecessary copying of nodes.  It 
should be possible to move all nodes quickly by doing everything in reverse 
outline order.  This will actually happen at two levels:  parent nodes will 
be processed in reverse outline order, and each parent's children will be 
processed in reverse sibling order.  

There should be no need to create "protected" copies of organizer nodes in 
holding cells.  Instead, all organizers (except existing organizers) will 
be created as "floating" positions.  Rather than moving the organizers 
(unlinking and linking), the organizers will simply be linked (low-level 
vnode code) at their final position. In the new scheme, we can expect 
extremely fast operation, comparable to the 0.06 sec taken by demote.

There is a surprising similarity between today's work with 
vc.find_position_for_relative_unl. The old find_position_for_relative_unl 
code endlessly stepped through children, searching for a match.  Unless we 
are careful, the new move code would have to endlessly adjust positions.  
Doing everything in reverse should eliminate all such adjustments.

Finally, new measurements indicate some other opportunities for speedups, 
possibly including trial writes.

Edward

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to