Add a word in the manual about performance of keyword arguments

[nalimilan]

I'm still not clear about what are the performance implications of keyword arguments, and I recently noted on the mailing list that I'm not the only one. So I think we should add something to the manual about it.

If I understand correctly [1], methods are specialized based on the type of keyword arguments, just like for positional ones, but type inference on the result is not good. There's also an overhead on function calls due to matching keyword arguments. Is that right? Does it still improve performance to use a method with keyword arguments as a mere wrapper for an internal version with only positional arguments?

Finally, it could be good to specify which performance issues are expected to be solved at some point, and which ones are by design. When designing an API, one may prefer taking a (reasonable) performance penalty in the short term and benefit from the nicer function signature in the long term.

1: https://groups.google.com/d/msg/julia-users/iFo6RmppCkE/NbVGcNPmB_oJ

[mauro3]

There is something about keywords in the performance section of the manual. But it is not clear on the points you mention here. See also comments issue #9551.

[simonster]

@nalimilan At least by my understanding, your description sounds about right. Keyword arguments are implemented internally by creating a Vector{Any} of keyword/argument pairs, sorting them, and passing them as positional arguments to an internal function. As a consequence, type inference for the return type is constrained only by the types of the keyword arguments in the method definition and not by the types the method is called with. There is no reason to use a method with keyword arguments as a wrapper for an internal version because that's how they're implemented anyway.

If no keyword arguments are passed to a function that could accept keyword arguments, then the Vector{Any} construction and sorting steps are elided, so there's no overhead, and type inference uses the inferred types of the specified defaults to determine the return type. If you're not careful you can easily create a function that is inferred correctly when no keyword arguments are passed, but is inferred as Any if some or all of the keyword arguments are passed.

[kshyatt]

Is this still not documented well?

[KristofferC]

Think this can be closed with the new keyword implementation.