@dnolen The self call can be fixed by changing the defn macro in core.cljc:

(core/list 'def name
                 ;;todo - restore propagation of fn name
                 ;;must figure out how to convey primitive hints to self calls first
                 (cons `fn (cons name fdecl)))

By propagating the function name the analyzer will do the two passes and optimize the call.

I'm not sure if that's the right approach though.

hrm I don’t know what my point about primitive hints was in this context anymore

emitting (defn foo -> (def foo (fn foo rather than just (def foo (fn has semantic differences, at least in clojure

propagation of the fn name seems simple, any expedient approach will do - should be considered detail anyway

clojure filp flopped between the two and the current behaviour is the latter

not sure if the same issues apply in cljs

issues being around e.g. redefs

see trying to memoize self-calls of a (def foo (fn vs (def foo (fn foo

@rauh, ah so that’s the problem, the anon fn name shadows the top level name

@bronsa right

@rauh hunch - a simple metadata hack will probably suffice

@dnolen I don't see any different JS emitted if the function is given a name. Either way it'll end up with the munged name after (function ...(...){...})

Google closure will also not remove the function name if it's being called recursively (it seems)

@rauh just changing the macro isn’t going to be enough

you need to look at the 'def case in the analyzer

I'm getting very slow compilation on for expressions

especially nested ones

for example:

(defn nested-table [table]
     (for [x table]
       (for [j table]
         (for [k table]
           1))))

this takes over 14.7 seconds to compile using cljs.js/eval-str

does anyone know why this is and where I should look to understand it?

@ericnormand is (for [x table j table k table] 1) faster?

I'm not sure but it's not what I'm looking for

I'll try it

it's about 4 seconds

from mention of cljs.js/eval-str this is self-host I guess?

yeah

@ericnormand it would be useful to know which ClojureScript version you’re running that with

there was a slight perf regression in self-host a while ago that was fixed

[org.clojure/clojurescript "1.9.456"]

right, so if you upgrade to a version post 1.9.473 it should be much faster (any version after this commit https://github.com/clojure/clojurescript/commit/aa00c033c838692562d0d96dc86b74dc2a1a9b06)

thanks, I'll try that

On my machine with lumo 1.5.0 - cljs 1.9.542 I get:

time lumo -e "(defn nested-table [table]
  (for [x table]
    (for [j table]
      (for [k table]
        1))))"
#'cljs.user/nested-table
lumo -e   1.46s user 0.09s system 135% cpu 1.149 total

yep

mine is similar

1.46 sec!!!

it may be the compiler

even with a single for loop it’s slow

lumo -e "(defn nested-table [table]   (for [x table] 1))"  
0.73s user 0.06s system 132% cpu 0.601 total

woah

with new cljs, it's way faster

first time: 1.5 s

second time 0.952 s

not bad

that might make the difference

[org.clojure/clojurescript "1.9.542"]

even though it’s much faster after that perf commit, I still think there might be something wrong with macroexpansion in self-hosted CLJS

I just haven’t had the time to look into it

Interestingly, macroexpand is much faster than eval

time lumo -e "(macroexpand '(defn nested-table [table]   (for [x table] 1)))"
 0.24s user 0.05s system 108% cpu 0.260 total

@viebel That only expands the defn not the for

@viebel yeah you wanna use something like https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/pprint.cljc#L83

it's not complaining about clojure.spec

do I need to require it?

no

it just won’t perform any checks expanding the macro

hmm

how can I require it if I want to?

oh, I see

never mind

thanks @anmonteiro

np!

for also emits the body twice, so there is potential for (code size) optimization.