Fork me on GitHub
#cljs-dev
<
2017-05-16
>
rauh16:05:17

@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)))
;; Note: Comments where already there.

rauh16:05:42

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

rauh16:05:53

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

dnolen16:05:24

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

bronsa16:05:15

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

dnolen16:05:21

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

bronsa16:05:40

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

bronsa16:05:10

not sure if the same issues apply in cljs

bronsa16:05:17

issues being around e.g. redefs

bronsa16:05:36

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

dnolen16:05:49

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

dnolen16:05:32

@rauh hunch - a simple metadata hack will probably suffice

rauh17:05:39

@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 ...(...){...})

rauh17:05:01

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

dnolen17:05:38

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

dnolen17:05:48

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

ericnormand17:05:06

I'm getting very slow compilation on for expressions

ericnormand17:05:12

especially nested ones

ericnormand17:05:19

for example:

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

ericnormand17:05:53

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

ericnormand17:05:28

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

favila17:05:51

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

ericnormand17:05:10

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

ericnormand17:05:10

it's about 4 seconds

favila17:05:42

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

anmonteiro17:05:52

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

anmonteiro17:05:08

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

ericnormand17:05:09

[org.clojure/clojurescript "1.9.456"]

anmonteiro17:05:51

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)

ericnormand18:05:36

thanks, I'll try that

Yehonathan Sharvit18:05:10

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

Yehonathan Sharvit18:05:15

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

ericnormand18:05:21

mine is similar

ericnormand18:05:26

it may be the compiler

Yehonathan Sharvit18:05:13

even with a single for loop it’s slow

Yehonathan Sharvit18:05:17

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

ericnormand18:05:59

with new cljs, it's way faster

ericnormand18:05:18

first time: 1.5 s

ericnormand18:05:32

second time 0.952 s

ericnormand18:05:08

that might make the difference

ericnormand18:05:26

[org.clojure/clojurescript "1.9.542"]

anmonteiro18:05:20

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

anmonteiro18:05:25

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

Yehonathan Sharvit18:05:40

Interestingly, macroexpand is much faster than eval

Yehonathan Sharvit18:05:49

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

rauh18:05:28

@viebel That only expands the defn not the for

ericnormand18:05:07

it's not complaining about clojure.spec

ericnormand18:05:12

do I need to require it?

anmonteiro18:05:33

it just won’t perform any checks expanding the macro

ericnormand18:05:28

how can I require it if I want to?

rauh18:05:09

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