Make param.depends efficient about param HOT 6 OPEN

Enabling cache with param.depends should be done carefully as a method can have state information not put into the decorator but available in the class itself, making it a very hard problem.

from param.

Caching param.depends is effectively an absolute no-go for that reason. In the case of pn.bind you can at least have a reasonable expectation that the function is only dependent on the state of the arguments and memoize on those, in the case of pn.depends (especially in a class setting) you could memoize on the explicitly stated dependencies but that still seems quite implicit and that assumption will break in certain scenarios.

from param.

@MarcSkovMadsen can you quantify how inefficient param.depends is?

from param.

I mean param.depends itself isn't inefficient, the problem is that it can lead users to write inefficient code. So I'd say it's at least partially a usage and documentation issue. It's perfectly possible to write apps using depends that cache intermediate results on parameters, in fact that's a pattern I use relatively frequently, i.e. instead of doing this:

class Adder(param.Parameterized):
    a = param.Number()
    b = param.Number()

    @param.depends('a', 'b')
    def result(self):
        return self.a+self.b

you write:

class Adder(param.Parameterized):
    a = param.Number()
    b = param.Number()
    result = param.Number()

    @param.depends('a', 'b', watch=True)
    def _calculate(self):
        self.result = self.a+self.b

When using bind on the other hand there is no obvious way to cache the result.

from param.

I mean param.depends itself isn't inefficient, the problem is that it can lead users to write inefficient code. So I'd say it's at least partially a usage and documentation issue. It's perfectly possible to write apps using depends that cache intermediate results on parameters, in fact that's a pattern I use relatively frequently, i.e. instead of doing this:

class Adder(param.Parameterized):
    a = param.Number()
    b = param.Number()

    @param.depends('a', 'b')
    def result(self):
        return self.a+self.b

you write:

class Adder(param.Parameterized):
    a = param.Number()
    b = param.Number()
    result = param.Number()

    @param.depends('a', 'b', watch=True)
    def _calculate(self):
        self.result = self.a+self.b

When using bind on the other hand there is no obvious way to cache the result.

Agree with Philipp. The main problem is that the bound functions are called the same number of times as you depend on them instead of one time.

The examples I provided are the same as Philipp provided. Philipp second example look simple, but if you start having multiple parameters to update it becomes less obvious what goes on. I think its friction that you have to write that extra boiler plate code in every Parameterized class you write instead of just providing a cache=True or cache=('a','b') parameter to param.depends or similar.

from param.

I don't buy the argument of having state that is not-depended on. Right now without concrete examples I believe that is an antipattern.

Pro adding caching I would also argue that

• There is a huge difference in how parameters and bound functions are treated by Panel. Parameters are displayed using widgets and bound functions using panes. Thus if a bound function is inefficient and I change to a Parameter+watch=True implementation its not only the Parameterized class that needs to change. Its all the places where its used.
• Caching is not built into Param. Its built into Panel (pn.cache) thus you cannot actually build the caching your self in the Param world. Making it even harder to make your Parameterized classes efficient and optionally using it in Panel.
• "Modern" frameworks are "React" like. And the ones I've seen in Python does the caching automatically for the user (as well as the "parameter" dependency resolution).

from param.