Performance

What can we do to make this fast? At the moment, calling j.sin is 10x slower than math.sin or numpy.sin.

I’m guessing that this is due to type inference issues with the PyCall.jl callback. Is there a way we could provide annotations or hints for individual functions?

[simonbyrne]

My (possibly quixotic) purpose was thinking about how we can make Julia an easy-to-use replacement for C for writing Python backend code. Where is the overhead, and what could we do to make it slimmer?

[stevengj]

@simonbyrne, but users normally only write Python backend code in C or Cython or whatever for big, expensive functions. That’s why everything in NumPy is vectorized, after all. And for big, expensive function, the function-call overhead shouldn’t matter.

Part of the overhead comes in converting the argument to a Julia type. Since PyCall does not know what kind of Python object you are passing, it has to convert(PyAny, args)... on the tuple of arguments. This, in turn, needs to check what Julia type it should try to convert to. The way this is done is a naive list of if statements right now … it could be improved a lot if we used e.g. some kind of hash table to memoize the results based on the PyObject_Type.

Of course, something like sin could be made faster (but much less flexible) if we only check for one or two possible types. And you could avoid the dynamic dispatch on the Julia side too.