@dnolen @favila @rauh to pick on the str issue, there is a measurable gain in the solution @rauh proposed

https://jsperf.com/cljs-str-perf

current impl is 27% slower in chrome, 73% slower in safari, 80% slower in firefox (on my machine, macbook, no IE)

45% chrome, 80% FF here

IMO, it's such a simple change that makes sense even just for the sake of allowing GCC to pre-concat strings and not emitting code like str("some str").

I agree.

It decreased the js code for me by 1.5%, which seems tiny, but a few of those changes... And it adds up.

Here is another one: In destructure if, instead of checking if the passed val is a map/seq inline (as it's done right now) and instead create a function like ensure-map we'd decrease size + be about 10% (FF) 30%(Chrome) faster. Significant? No, but a small improvement. (all tested in advanced builds)

Would there be an even bigger benefit to getting rid of macro-generated [].join() alltogether? (using +)

This was my original approach: CLJS-801, but was wrongly implicated in the Safari x.toString() debacle and backed out

I found that [].join is much faster in FF than +. Not so in chrome.

even for constants?

rather, for literals

Well we shouldn't join constants, that's argument #1 🙂

I mean a+b+c+d+e+f (where all args are known) vs appending to a string in a loop

the former is the macro case, the later the str function case with many args

https://jsperf.com/cljs-str-perf

well, StringBuffer uses +=

added that test as well

but given the history of invalid results we should be careful with that I think

it it faster though

oh crap

just noticed an error

https://jsperf.com/cljs-str-perf fixed the error, please re-check results

FF still looks faster with + to me

Yeah, same. I wonder what I measured the other day 🙂

@thheller Why did you remove the testcase where the str function just returned x instead of [x].join("")?

that gives incorrect results with + on the outside

I only want to change one thing

that too

http://dev.clojure.org/jira/browse/CLJS-890?focusedCommentId=37324&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-37324

Unfortunately due to dropbox killing public folders I can't get that jsperf working again

but the msg reminded me that ''+[x] is also an alternative to [x].join("") to avoid x.toString()

I'm still getting FF being much faster with join than for +

yeah results are mostly unchanged from before, just wanted to be correct. + is faster by a lot in every engine

Does Firefox use ropes for strings like the other browsers? That might be the reason join is faster

It should. It did two years ago last I tested. And honestly it's still faster now on my machine. @rauh what FF version and platform?

Using FF 52 on ubuntu I see + as 33% faster than join

Same version + Platform

32 or 64 bit?

but with a version of joining with a function that returns x if x is not null

so: function(x) { (x==null)?"":x}

well obviously forgot the return here... Too much clojure 🙂

found the old code for that jsperf that doesn't run

These were the str impls I tried 2 years ago

(str fn, not macro)

@favila Here is the test case that's faster in ff:

man that's weird

also weird, the fastest FF case is still slower than the slowest Chrome case

"inlined str +" is 5x on Chrome

micro-benchmarks like this are always a bit dangerous

but given that we all see similar results there is something to them