Fork me on GitHub
#clojure-italy
<
2017-06-29
>
reborg08:06:26

A casa col raffreddore, diciamo un po' piu' forte del solito...

skuro11:06:43

buon pomeriggio

bronsa11:06:35

@reborg eh con sti sbalzi di temperatura

reborg12:06:30

Quiz time. Data una map tipo (def m {:a1 1 :a2 2 :a3 etc...}) qual e' il modo piu' veloce (in media) di accedere ad un elemento (lasciando perdere Java interop)? 1. (get m :a3) 2. (find m :a3) 3. (:a3 m) 4. (m :a3)

reborg12:06:22

Holy labmda, rich hickey ad oxford in settembre... non manchero'

nilrecurring13:06:16

A occhio direi get, ma รจ solo intuitivamente e non ho assolutamente idea di cosa succeda sotto, di solito รจ tutto veloce abbastanza

reborg13:06:13

Vero, sono tutti molto veloci. sono quisquiglie da conversazione ๐Ÿ™‚ Si va da circa 40 nanosec a 20 nanosec

reborg13:06:24

get funziona con vari tipi e find deve construire comunque una mapentry sul risultato...

nilrecurring13:06:11

Vero ๐Ÿ™‚

nilrecurring13:06:29

(m :a3) รจ sorprendente in effetti

nilrecurring13:06:39

(non potevo resistere, ho aperto una repl)

reborg13:06:45

Se pero' mettiamo dentro java interop c'e' una sorpresa, 5. (.get m :a3)

reborg13:06:27

cioe', non e' piu' veloce in assoluto

bronsa13:06:34

se m e` un record (:foo m) e` il piu` veloce

bronsa13:06:45

altrimenti sospetto (m :foo)

reborg13:06:49

sto per postare un super-chart coi risultati

bronsa13:06:29

@reborg huh? .get piu` lento di invoke?

bronsa13:06:42

mi sembra molto strano, l'implementazione e` esattamente la stessa

reborg13:06:52

si non me l'aspettavo. sicuramente non e' reflection, che farebbe schizzare il tutto 1 ordine di grandezza

reborg13:06:01

posto il codice

nilrecurring13:06:46

Ohh che bel grafico ๐Ÿ˜„

bronsa13:06:17

@reborg riavviato la jvm tra test?

reborg13:06:00

(let [coll (into {} coll)] (b (coll k))) (let [^java.util.Map coll (into {} coll)] (b (.get coll k)))

bronsa13:06:32

scommetto se che riavvii la jvm tra un test e l'altro i risutlati saranno leggeremente diversi

bronsa13:06:09

altrimenti rischi che un benchmark precedente causi ottimizzazione/deottimizzazione di code path usati da uno successivo

bronsa13:06:35

per curiosita`, se hai voglia/tempo, sarebbe anche interessante usando un record

reborg17:06:41

defrecord e' 10x piu' lento del resto, e non puo' avere piu' di 255 attributi ๐Ÿ™‚

reborg17:06:21

gli altri si sono uniformati con il restart della jvm. vorrei provare una seconda volta poi posto un altro chart

reborg20:06:28

non ho messo defrecord nel chart che mi sballa tutti i risultati ๐Ÿ™‚ get e find vagamente piu' lenti, java interop e map a parimerito, keyword meglio di prima

reborg20:06:35

comunque si', a livello di pochi nanosecondi non c'e' praticamente differenza e cose tipo la posizione della key (che ora e' scelta random) possono influenzare il tutto

bronsa21:06:35

sarebbe interessante capire perche` i record sono cosi` lenti

bronsa21:06:02

magari ci do un'occhiata questo weekend