On Mon, Mar 29, 2010 at 1:30 PM, Terry Brown <[email protected]> wrote: > On Mon, 29 Mar 2010 12:48:43 -0500 > "Edward K. Ream" <[email protected]> wrote: > >> > I think Leo can handle trees with 4823 nodes, but [snip] >> >> Drawing large trees can be very slow when many nodes are visible. >> OTOH, Leo could probably handle trees containing a huge number of >> nodes provided only a few ever got expanded at any one time. > > I don't think it's a drawing issue (this should all occur withing a single > redraw), rather that p.insertAsLastChild() followed by modifications to p.b/h > doesn't perform as well for creating huge numbers of nodes. As compared to > the read code, for example. Now if you tell me the read code uses > p.insertAsLastChild(), it must be something else. Anyway, I think having a > plugin recursively indexing a directory of unknown size return after a > certain number of seconds has elapsed regardless of completion is a helpful > behavior.
I'm not saying that every possible way of creating .leo files will be fast, but Leo's read code is linear in the number of nodes. That is, every node gets handled in constant time, to first and second approximations. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
