small optimization to f(...; kw...) when kw is empty

[JeffBezanson]

Found a modest piece of low-hanging fruit here. In this case, we were "copying" the container kw to a new (empty) array, and then checking whether that is empty, when we could just check whether kw is empty. This comes up a lot in definitions like

call(f, args...; kwargs...) = f(args...; kwargs...)

(e.g. remotecall), where allocating an unnecessary empty array has significant overhead for what should be a no-op. This shaves off another ~10% of the memory allocated in the benchmark in #21543.

This also takes advantage of some common cases where kw has a known length, where before we always copied it using push!.

[JeffBezanson]

Ha, that failure was a good puzzle. Apparently @testset depended on the (unnecessary) for loop generated by keyword arg lowering to force toplevel expressions to be compiled, in order to get better backtraces.

[tkelman]

this doesn't seem fragile at all

[JeffBezanson]

Ok, suggest an alternative. There is a test for this at least.

[TotalVerb]

Would putting it in a let work?

[vtjnash]

I think this should be fine. If we change the front-end heuristics, we'll worry about this then. Probably by then backtrace scrubbing will be decoupled from compilation anyways.

[vtjnash]

But maybe put a comment on whichever test led you to notice this, as a breadcrumb for the next person who runs into this?

[tkelman]

@nanosoldier runbenchmarks(ALL, vs = ":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[Sacha0]

Chances are the potential regressions are noise. But it's dangerous to go alone, so take this tiny metal pegasus @nanosoldier runbenchmarks("array" || "sparse" || "tuple", vs = ":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[Sacha0]

The potential ["tuple","reduction",("sumabs",(4,))] and ["sparse","transpose",("ctranspose!",(20000,10000))] regressions are consistent across nanosoldier runs, but those two benchmarks are perennially noisy so I'm not certain what to make of that consistency...

[JeffBezanson]

They're consistently inconsistent :)

[JeffBezanson]

Interesting failure on os x. Log backed up:
https://gist.github.com/JeffBezanson/638cba8d73c1b46963e4971135db70ab