[Cuis-dev] Improving performance of tree-like morph

[Juan Vuletich]

On 10/13/2023 10:40 AM, Michał Olszewski via Cuis-dev wrote:
> Hello,
>
> I'm currently working on an AST visualizer. I'm using OMeta2 to create 
> a tree morph, representing a parse tree of the given source code.
>
> However I found if the tree is of depth like 5 or more (e.g. 
> left-associative binary operation) the time it takes to create 
> (openInWorld) or resize the tree is just... atrocious. I used 
> AndreasSystemProfiler and from quick look at it, it seems like there 
> is an explosion in number of operations attempting to layout morphs 
> e.g. everytime a child node morph is added then ALL submorphs' layouts 
> are recalculated.
>
> The morph representing a node is a subclass of LayoutMorph, which in 
> turn contains two layout morphs: One for representing a label (e.g. 
> node name) and the second one containing child nodes in left-to-right 
> order.
>
> Does anybody know how to make it relatively performant on depthly 
> nested trees? Or am I out of luck in terms of simple solution?
>
> Not attaching any source code since OMeta2 is needed for it. I managed 
> to make OMeta work on Cuis 6.0 (pbella's package) but sadly can't 
> remember how, otherwise I would provide a fix/package. I will try to 
> generate code that creates this god damn tree so you don't have to 
> install OMeta2.
>
> Best,
> Michał
>

Hi Michal,

Thanks for the image you sent me privately. It was very useful.

There was indeed a huge inefficiency when computing nested layouts. I 
just pushed an update to GitHub that solves the issue.

Cheers,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich