cljs-dev

p-himik 2023-12-08T15:47:01.484719Z

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.

πŸ‘ 1
βž• 6
dnolen 2023-12-11T13:59:06.297309Z

it’s worth experimenting with, not obvious what the implications might be (possibly nothing)

p-himik 2023-12-11T14:03:34.002989Z

Also worth noting that the Firefox profiler seems to be more clever in this regard - it did label those functions using the full path.

dnolen 2023-12-11T15:33:43.538729Z

similar work like this was done in the past

dnolen 2023-12-11T15:33:56.745989Z

I believe we did something like the following in some cases

dnolen 2023-12-11T15:34:15.626929Z

var x = function generatedNameForDebugging(…)

dnolen 2023-12-11T15:34:26.238809Z

because a more debuggers supported that pattern over

dnolen 2023-12-11T15:34:34.292119Z

var x = function() {}