Hi folks: I'm looking for suggestions, or tips, for a library. I want something like re-frame - I need to listen to events (onClick, onChange, onKeyUp, etc) and make then trigger other events/do actions. The trouble: these need to be configurable in user-space (imagine a user changing keybindings on an editor - that's exaclty one of the cases), it needs to be fast, and it needs to allow for async and sync dispatch (for example, if the user listen to an event onChange in an input, and decide to revert whatever was typed, I don't want the UI to flicker). The idea is to prototype a code editor. I'm even thinking about intercepting datascript transact! so I could have the app state in a quasi-real database, but I'm worried about subscribing to events. So, anyone have any suggestion? Even things like "yeah, re-frame is fast enough" can help! Thanks a lot! 🙂

Hi, all. Say, I am in position to add a clojuresript frontend to the existing clojure/java project. And I am also don't want to duplicate my "model" (entity maps, specs and so on) logic. Is it is acceptable approach to move model logic to the cljc files so it can be shared between frontend and backend? I am really interested in opinions here. I have seen a logic shared in cljc files, but I didn't seen (yet) a model logic shared in this way.

(defprotocol Foo)
(instance? Foo (reify Foo))

implements? isn't documented but reading it I think that it would be faster than satisfies? - at least, it is nearly the same code just eliding the branch that checks native-satisfies?

(moved the rationale for why the instance? check does not work to #cljs-dev)

@lilactown would this be a good reason to introduce a deftype that implements a protocol rather than using reify ?

the implements? check isn't in a very hot spot though, so using implements? or even satisfies? is fine here. just wonder if there are other benefits to not using reify and rather moving to a deftype in CLJS. it still seems to be very fast with reify

hmm

cljs.user=> (defprotocol Foo)
false
cljs.user=> (deftype Bar [] Foo)
cljs.user/Bar
cljs.user=> (instance? Foo (->Bar))
false

Making a type seems to have a performance edge when invoking the protocol function on it though

@borkdude this is not a property of reify but protocols in general. they do not add themselves as parent objects in JS prototype chains, so instance? will always return false if you're checking if something implements a protocol

you ought to use implements? for this

makes sense, thanks.

it seems weird to me that it works on the JVM tbh. I assume it's a property of how protocols are reified and interact with the Java object model

if I make a type I can just do the instance check on the type though, this is what I did before

that's true. if you know something will always be of a concrete type, it's much faster to check

I can arrange it as such

would there be any reason why invoking a protocol fn on a reify would be slower than on a typed instance (deftype) in CLJS?

I'd have to see the code. I would think that dispatching would be the same, but constructing the object may be slower for reify

i.e. the difference may be in (reify ,,,) vs (->Type ,,,)

I did a huge refactor to go from a type that wraps a function to a protocol because it was slightly faster in Clojure, but now I'm discovering it's way slower in CLJS :/ I hope I can speed it up using some tricks still.

I'm not referring to the construction, only to the invocation

> from a type that wraps a function to a protocol not sure what this means. I thought you were asking about protocols via reify vs protocols via deftype

yes. so first I had this:

(deftype Foo [f])

(if (instance? Foo ...) ((.-f obj) ... ...) ...)

and now I went to:

(defprotocol IFoo (invoke [_]))
(invoke (reify IFoo (invoke [_])))

the second one is way slower in CLJS unfortunately

but faster in Clojure.

I mean, pull out the construction in a let

and then invoke many times

ok, and what about

(defprotocol IFoo (invoke [_]))

(deftype Foo [f] IFoo (invoke [_] (f)))

(let [foo (->Foo)]
  (invoke foo)) 

I thought that's what we were comparing reify to

that's what I'm considering next

and was asking about

method/property invocation is quite fast in JS. hard to get faster than ((.-f obj) ,,,)

Exactly. Then why is using protocols faster in Clojure :(

I mean, it's a cost to maintain two different styles

you can see what the JS code is doing for this code

(defprotocol Foo
  (bar [o]))

cljs.user.Foo = function(){};

cljs.user.bar = (function cljs$user$bar(o){
  if((((!((o == null)))) && ((!((o.cljs$user$Foo$bar$arity$1 == null)))))){
    return o.cljs$user$Foo$bar$arity$1(o);
  } else {
    var x__18528__auto__ = (((o == null))?null:o);
    var m__18529__auto__ = (cljs.user.bar[goog.typeOf(x__18528__auto__)]);
    if((!((m__18529__auto__ == null)))){
      return m__18529__auto__.call(null,o);
    } else {
      var m__18526__auto__ = (cljs.user.bar["_"]);
      if((!((m__18526__auto__ == null)))){
        return m__18526__auto__.call(null,o);
      } else {
        throw cljs.core.missing_protocol.call(null,"Foo.bar",o);
      }
    }
  }
});

how clojure compiles protocol invocations isn't clear to me, I just know "clojure protocols are fast"

have you profiled your code?

you might also test this using optimizations, the difference may be smaller

I have profiled yes, using advanced. Btw, I now see that reify or type doesn't really make a difference (from this simple benchmark).

cljs.user=> (defprotocol IFoo (invoke [_]))
cljs.user=> (deftype Dude [] IFoo (invoke [_] (inc 1)))
cljs.user=> (let [f (->Dude)] (simple-benchmark [f f] (invoke f) 1000000000))
[f f], (invoke f), 1000000000 runs, 21015 msecs
nil
cljs.user=> (let [f (reify IFoo (invoke [_] (inc 1)))] (simple-benchmark [f f] (invoke f) 1000000000))
[f f], (invoke f), 1000000000 runs, 21122 msecs
nil
cljs.user=> (deftype Foo [f])
cljs.user/Foo
cljs.user=> (let [f (->Foo inc)] (simple-benchmark [f f] ((.-f f) 1) 1000000000))
[f f], ((.-f f) 1), 1000000000 runs, 6447 msecs
nil

((.-f f) 1) may just be more JIT friendly

but it also elides all the checks you see in the output above

damnit, a whole day of refactoring... bummer :)

sorry 😞

I wonder if there would be room for an "unguarded" protocol dispatch in cljs.core

maybe I can patch it for my own protocol?

in the case you have above you ought to be a able to compile it to

o.cljs$user$IFoo$invoke$arity$1()

maybe I can invoke that sucker directly?

you might be able to do it via a macro

cljs.user=> (let [f (reify IFoo (invoke [_] (inc 1)))] ((.-cljs$user$IFoo$invoke$arity$1 f)))
2

cljs.user=> (let [f (reify IFoo (invoke [_] (inc 1)))] (simple-benchmark [f f] ((.-cljs$user$IFoo$invoke$arity$1 f)) 1000000000))
[f f], ((.-cljs$user$IFoo$invoke$arity$1 f)), 1000000000 runs, 496 msecs
nil

now we're talking

Using that "patch", it's close enough to the (.-f ..) approach:

cljs.user=> (let [f (reify IFoo (invoke [_] (inc 1)))] (simple-benchmark [f f] (invoke f) 1000000000))
[f f], (invoke f), 1000000000 runs, 7400 msecs
nil

Eh, the patch being:

cljs.user=> (set! cljs.user.invoke (fn [this] ((.-cljs$user$IFoo$invoke$arity$1 this) this)))
#object[Function]

does that survive advanced optimizations?

I wonder about that too

but that's easy enough to find out

I think it would

that's great!

I don't think this is going to work out though

the check is there for objects that do not have this method attached to them, e.g. if you would extend the protocol to :default and pass a number or string which does not implement the protocol

yeah that's right. you are giving up some amount of polymorphism for speed

I thought for your case you could rely on a concrete type being passed in?