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

Juan Vuletich juan at cuis.st
Mon Oct 23 12:37:27 PDT 2023

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.


Juan Vuletich

More information about the Cuis-dev mailing list