Would it be reasonable to compile multi-arity functions in such a way so that their concrete arity "children" get proper function names?
E.g. (defn x ([] 0) ([_] 1)) gets compiled to something like this:
cljs.user.x = (function cljs$user$x(var_args){
var G__33 = arguments.length;
switch (G__33) {
case (0):
return cljs.user.x.cljs$core$IFn$_invoke$arity$0();
break;
case (1):
return cljs.user.x.cljs$core$IFn$_invoke$arity$1((arguments[(0)]));
break;
default:
throw (new Error(["Invalid arity: ",cljs.core.str.cljs$core$IFn$_invoke$arity$1(arguments.length)].join('')));
}
});
cljs.user.x.cljs$core$IFn$_invoke$arity$0 = (function (){
return (0);
});
cljs.user.x.cljs$core$IFn$_invoke$arity$1 = (function (_){
return (1);
});
cljs.user.x.cljs$lang$maxFixedArity = (1);
As you can see, cljs.user.x gets a proper name - cljs$user$x.
cljs.user.x.cljs$core$IFn$_invoke$arity$0 and cljs.user.x.cljs$core$IFn$_invoke$arity$1, on the other hand, don't get it.
The issue is that the Chrome profiler treats those functions as anonymous, making profiling harder than it should be.itβs worth experimenting with, not obvious what the implications might be (possibly nothing)
Also worth noting that the Firefox profiler seems to be more clever in this regard - it did label those functions using the full path.
similar work like this was done in the past
I believe we did something like the following in some cases
var x = function generatedNameForDebugging(β¦)
because a more debuggers supported that pattern over
var x = function() {}