consider changing the antlr4 tree transformation logic about parcera HOT 3 CLOSED

This comment could be very presumptuous on my part, but it sounds like you don't know what the performance issue is at the moment (I don't either) the danger with this scenario will be guessing solutions and potentially wasting effort when you find the guesses + implementation aren't fruitful

Sounds like an ideal time to try and profile code: https://stackoverflow.com/questions/2974916/profiling-tool-for-clojure hope this helps

from parcera.

This comment could be very presumptuous on my part

@slifin not at all. At least I dont perceive it like that :)

Sounds like an ideal time to try and profile code: https://stackoverflow.com/questions/2974916/profiling-tool-for-clojure hope this helps

I know the options to profiel clojure code already and I am using VisualVm 😅. The problem is that base on my experience with profiling Clojure, lazy sequence are very difficul to profile because the "work" doesnt happen inmediately but it is differred to the consumer.

Furthermore, in this case the transformation is deeply recursive so I dont know if keeping all those elements on the stack can affect performance or not. On the other hand, Clojure immutable collections are ihnerently slower than java/js mutable ones so for upmost performance that might be an option. The question is then which bullet would I have to take ?

from parcera.

closing this.

After several checks I found out that the convertion between antlr objects and clojure ones was not the issue. The issue was that I was measuring the roundtrip of source code -> ast -> source code which is of course not representative of the source code -> ast transformation.

The roundtrip does in fact take much longer than plain ast creation.

However, plain ast creation takes around 30 ms on my machine for the clojure.core namespace and traversing it with tree-seq only adds a couple milliseconds more.

If anyone else finds some performance issues please let me know.

from parcera.