Performance issues

[jcubic]

I'm not sure if there is a fix for this.

Here are a few examples of slowness:

Preact app that updates SVG, was required to add debounce because it was really slow:
https://codepen.io/jcubic/pen/PojYxBP

Here is an example of ReactJS code that blocks the main thread for ~300ms, the more code there is in the Component the slower the code is.

Another example is the Function Reference generator:
https://github.com/jcubic/lips/blob/master/scripts/reference.scm
The code defines a function name-compare that is used on Array::sort and a big array.

If this is not fixed there is no point in showing ReactJS in LIPS.

When running a performance test in the browser there are a lot of macro calls, maybe adding expansion time for macros will solve the issue. To consider adding expansion time in 1.0.

[tluyben]

What is the reason the reactjs part is so slow? Is the reason the parser like in reference.scm or (I assume) something else?

[jcubic]

@tluyben I think it's slow because LIPS is a tree walking lisp and it needs to evaluate the code on each update. This is exactly the same as with reference.scm. React invokes the code multiple times which is normal because only the DOM update is slow. But with LIPS the invocation of the code is slow.

And the code may be slow because it does a lot of patching of JavaScript objects so LIPS can better interact with JavaScript. I can try again to run the profiler and see what takes most of the time, maybe there is something I can do to speed this up. I did some optimization but it didn't speed things a lot.

[jcubic]

Another possibility is that maybe the code is slow because of macros are invoked at runtime. There is a plan to rewrite the macro system so they are actually evaluated at compile time. But it makes take a while before this gets implemented.

[the-man-with-a-golden-mind]

Hmm maybe the issues are on the both of the sides. React is quite specific. Maybe approach from Imba with memorization would be a better fit for Lips. Another thing is ... that without incremental compilation compiling macros on each compilation can be dangerous (look at Rust...it can takes a lot of time)

[jcubic]

Yes, macros are one of the bottlenecks. Right now they are like functions, executed at runtime. There is a plan to rewrite both macros systems to be executed at parse time (actually there will be added compilation time when macros will be expanded). But I'm not sure when this will be implemented. I don't work on that project much recently. I only hope that if finally implemented two-step (compilation of macros and interpretation) will not break syntax extensions.