wip for a generic and/or optimization pass - https://github.com/clojure/clojurescript/compare/opt-if

should hopefully fix the long outstanding core.async bugs

one interesting result is this is fully generic and does not rely on form tagging

it will just try to optimize any trivial let/test/if combo

so actually it optimizes far more than the macro since, even if the first part of a thing can't be optimized, it can optimize the rest

i.e. (and some.ns/x true false)

this and fixing handling of #js literals would fix up the two big CLJS core.async pitfalls

I had stalled a bit on this previously because I thought type inference was needed

but now it's clear that this pass just runs after type inference

quick check in the repl and this fixes both https://clojure.atlassian.net/browse/ASYNC-91 and https://clojure.atlassian.net/browse/ASYNC-158

@dpsutton nice - still working through the test cases

i'm interested to see what you do for that

just a bunch of annoying variations but we should have explicit tests

I want to turn this on and know it's more or less going to work

here are the two repros from those issues if you want them handy

@dpsutton yeah I'm not so worried about the core.async tests

just removing the and/or macro stuff makes the problem go away of course

the tests I'm writing now are about checking that all desirable scenarios do optimize

the and/or optimizations are on the critical path

it's probably not obvious why, but it's one of the most important optimizations we do

a quick summary is that and/or produce let

but let can go anywhere in the emitted code, so it's wrapped in an IIFE

but that is a performance destroyer

compound boolean expressions are in the persistent data structure code

this stuff can never include an IIFE

nor a truth test

oh i knew that optimization was important but didn't think about it being used in the core data structures

probably the single most important automatic optimization for that code

otherwise would have to write really strange ClojureScript

yeah makes sense. just hadn't considered that.

https://github.com/clojure/clojurescript/compare/opt-if

eye balling the persistent data structure code looks good

no detectable regression in compiler performance at least from compiling all of the runtime tests

it is done - https://github.com/clojure/clojurescript/commit/927f221f8fc26a49db7d0dcfd1d70008a986fd8f

would be nice to give master a try on your projects if you have a chance

sure, anything in particular we should pay attention to?

also no detectable compiler performance change for our production build

and nothing apparent wrong at runtime either after just a bit of testing

Just bumped up to https://github.com/clojure/clojurescript/commit/927f221f8fc26a49db7d0dcfd1d70008a986fd8f . I get this error when compiling during dev: [Wed May 12 2021 13:54:01.150]  ERROR   [TypeError: logger_SINGLEQUOTE_.setLevel is not a function. (In ‘logger_SINGLEQUOTE_.setLevel(lvl)’, ‘logger_SINGLEQUOTE_.setLevel’ is undefined)] … but I have a feeling that’t not part of ClojureScript per-se. I have a hard time isolating where it’s coming from at the moment. The stacktrace does not look very helpful.

Going to try compiling & running under :advanced

@raspasov from which version did you bump? this sounds more like one of the breaking changes from the .844 release: https://clojurescript.org/news/2021-04-06-release#_noteworthy_breaking_changes

From the latest (I’m aware of those)

From 1.10.844

ok, then sorry for my noise

No problem.

:advanced seems fine. Perhaps something in figwheel-main during :dev. Gotta investigate more.

Yes, it’s from figwheel-main

@raspasov were you on 844 before

Oh sorry see the backlog - seems odd though there were some other changes

For the and/or change no news is the best news

I guess and/or change could cause runtime improvements but probably only in lower level code

I believe it’s coming from this line: https://github.com/bhauman/figwheel-repl/blob/master/src/figwheel/repl/logging.cljs#L63

I’m guessing (could be wrong) because there’s an if statement that depends on the clojurescript-version it might not be selecting the proper logger since it’s a :sha version? https://github.com/bhauman/figwheel-repl/blob/master/src/figwheel/repl/logging.cljs#L19

But this is a figwheel issue; As far as I can tell, the ClojureScript changes are fine.