Hi Atamert,
I'm not an expert but I believe REPL does compile the forms you enter to
> bytecode. It compiles an fn form into a JVM class that implements IFn. It
> also compiles a quoted form (such as `(fn ...) ) but this time it takes the
> form of a list (as in (list ...) ), IOW it's still dat
On Thu, Jul 3, 2014 at 11:55 PM, Pascal Germroth
wrote:
> Hi Atamert,
>
> Here's a gist with the example code:
> https://gist.github.com/neapel/4e502a14e3738b709672
>
> I tried replacing a closure with a dynamically built and evaluated
>>> metafunction but discovered that it was actually slower.
On Thursday, July 3, 2014 7:27:24 PM UTC+1, adrian...@mail.yu.edu wrote:
> "No I'm benchmarking the functions returned by f1-4."
>
> Where did I say different?
>
I understood "Your original example called eval in the body of the
functions that you're benchmarking" as meaning I was running some
"No I'm benchmarking the functions returned by f1-4."
Where did I say different?
In any event, I'm trying to help you understand why your benchmarking
results are not aligning with your expectations and assumptions about the
code you wrote.
I would really like to help you gain a greater und
On Thursday, July 3, 2014 6:15:32 PM UTC+1, adrian...@mail.yu.edu wrote:
> I'm not sure I understand what you're saying here. :( Your example is
> simply benchmarking the same bit of code in each form. Why would evaluating
> one explicitly affect that benchmark? Your original example called eval
I'm not sure I understand what you're saying here. :( Your example is
simply benchmarking the same bit of code in each form. Why would evaluating
one explicitly affect that benchmark? Your original example called eval in
the body of the functions that you're benchmarking. That is where the
over
On Thursday, July 3, 2014 5:19:56 PM UTC+1, adrian...@mail.yu.edu wrote:
>
> You're going down a rabbit hole here. Evaluating forms at runtime will
> always result in a slower execution time than a function that doesn't
> evaluate a form at runtime.
>
I thought that was the whole point of Clo
You're going down a rabbit hole here. Evaluating forms at runtime will
always result in a slower execution time than a function that doesn't
evaluate a form at runtime.
On Thursday, July 3, 2014 11:55:02 AM UTC-4, Pascal Germroth wrote:
>
> Hi Atamert,
>
> Here's a gist with the example code:
Hi Atamert,
Here's a gist with the example code:
https://gist.github.com/neapel/4e502a14e3738b709672
I tried replacing a closure with a dynamically built and evaluated
>> metafunction but discovered that it was actually slower.
>>
>
> If evaluating code during run is slower than AOT compiling i
Hi Pascal,
On Wed, Jul 2, 2014 at 10:19 PM, Pascal Germroth
wrote:
> I tried replacing a closure with a dynamically built and evaluated
> metafunction but discovered that it was actually slower.
>
If evaluating code during run is slower than AOT compiling it, it wouldn't
surprise me.
> I gu
It gets even weirder. I tried this hoping it would create a closure like f1
does:
(defn f4 [x] (eval `(let [[x#] ~@[[x]]]
(fn [y#]
(= x# y#)
And indeed using no.disassemble in my test cases f1 and f4 always create
the same bytecode: a clojure.la
Hi,
I tried replacing a closure with a dynamically built and evaluated
metafunction but discovered that it was actually slower.
Here's a minimal example:
(defn f1 [x](fn [y ] (=x y )))
(defn f2 [x] (eval `(fn [y#] (= ~x y#
(defn f3 [x] (eval `(fn [y#] (= ~@[x] y#
(use 'c
12 matches
Mail list logo