ptest2 and ptest behave the same, but ptest2 is much slower...

How did you measure?

Also, it helps having the full code - including imports and tests. Apart from helping with reproducing the issue, what you think is the most important part can easily end up being completely irrelevant.

I am using those functions to sort a list of nested maps (count about 900)

What I find "weird" is that if I evaluate ptest and ptest2 in the REPL I get the following:

user> ptest
#function[user/ptestF]
user> ptest2
#function[user/prepare-specter-fn/fn--445128]

Does that ring any bells?

That's irrelevant - those are just automatically generation function names.

ok... for the rest, I think the example should provide enough context for figuring out the issue?

in my very limited clojure knowledge, the resulting functions (`ptest` and ptest2) should be the same, but I am obviously missing something

What does load-string do?

It's a clojure-core function (https://clojuredocs.org/clojure.core/load-string)

reads and evaluates a form

A minimal reproducible example would be perfect, yes.

Ooops, sorry, thought it was some custom implementation 😄

Specter’s macros try to compile the given argument for optimal performance. Macros are evaluated at read time. For ptest, all information is available at macro read time:

(def ptest #(select-first (load-string pathExpStr) %))

(defn prepare-specter-fn [specterPathStr]
  #(select-first (load-string specterPathStr) %))

The above statement is incorrect. pathExprStr is a string in run time, not compile time. load-string is not a macro. select-first is a macro but it doesn't do any job - it just replaces itself with a couple of function calls that are done in run time. From that point of view, ptest and ptest2 are completely equivalent.

Same thing if I don't use specter:

(defn prepare-fn [exp]
  #(get-in % (load-string exp) ))

(defn prepare-sort-fns [sortAttrs]
  (mapv #(prepare-fn (:sortExpression %)) sortAttrs))


(def ptest (sort-by #(get-in % [:some-attr]) col))


(def sortAttrs [{:sortExpression "[:some-attr]"}])

(def ptest2 (first (prepare-sort-fns sortAttrs))

if I do sort-by with ptest it's fast, while if I do it with ptest2 it's very slow

@U2FRKM4TW — select-first expands to a form that uses another macro: path. This one looks into &env for whatever smart thing specter does. I suspect that this can do optimisations when the path is known at macro-compile time that it cannot do otherwise.

@U031CHTGX1T it doesn't matter, I have given an example without specter (using get-in instead) and it's the same problem...

No, it’s not the same. One example uses load-string, the other one uses the parsed result. How can you expect these to perform the same?

@U031CHTGX1T Huh, you're right, thanks. One more reason for me to dislike Specter, heh.

@U013100GJ14 In your get-in example, try loading the string only once and see how it compares:

(defn prepare-fn [exp]
  (let [p (load-string exp)]
    #(get-in % p)))

uh, thanks, @U031CHTGX1T, that seems to be the problem!

hmm, but still...

I will post a complete example without specter in the main thread, please reply there. And thank you so much for your help!

I have deleted the other post, does not contribute because of the bug @U031CHTGX1T quickly found 🙂

@U031CHTGX1T thanks again!!!

Fix your first example from [:encounter/id] to [:attr] and you will see they perform about the same

uh...

deleting question, does not contribute to anything due to a bug in source...

Is there already a proposed patch/issue for tools.namespace for this?

there is, the ask question links to the ticket, the proposed patch is slightly different

that monkey patch is just what I ended up with when I was having trouble with tools.namespace, I didn't dig into it a ton and I am not sure what behavior differences would result in the above vs the patch in jira