On Fri, Jul 14, 2023 at 9:45 AM Thomas Passin wrote: Leo's VNode class is the heart of Leo. It has a long history. It handles > clones two orders of magnitude faster than the MORE outliner. All of its > complications exist for a purpose. > > > Of course they do. The situation is something like when one denormalizes > some database tables. They "ought" to be normalized, it's good practice to > normalize them (to at least 3NF) but sometimes for performance reasons one > doesn't. But then it can be hard to update all the denormalized tables > correctly. I think it's no different with Leo. As I said, I probably > don't understand the ins and outs because I'm not familiar with this part > of the code or its history. >
My apologies for my earlier testy response. I'm glad we're still on speaking terms. Leo's history chapter <https://leo-editor.github.io/leo-editor/history.html> discusses Leo's evolution. The great divide <https://leo-editor.github.io/leo-editor/history.html#generators-ua-s-the-end-of-sync-problems-shared-tnodes> section discusses the so-called unified node world. No code remains from Leo's earliest history. We must make do with what git shows us. I *understated *the performance advantages of VNodes. Leo forms clones in constant time. In comparison, MORE took O(N**2) time to make clones. MORE could be much worse than 100x slower than Leo. Also, MORE made clones by copying trees, a significant storage allocation bug. Finally, MORE crashed often. Whatever Leo's problems, it hardly ever just goes away :-) 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS01n0%2B3w2ZZSKHtH4mEEKGAyZe8tdNNhXtkJ%2Bqfc7iYTQ%40mail.gmail.com.
