Temporarily disabling bindings for performance?

  • Hi,

    lets assume a pretty standard master-detail interface implemented
    with bindings.

    Now there are multiple variants of the detail part, separated into
    different views which are exchanged against each other on user
    request or depending on the selection in the master list.

    Is there an (easy) way to disable the bindings in the currently
    unused views? To my understanding these bindings stay live and eat
    CPU cycles even while a container view with the bound controls is not
    installed in a window.

    One approach would be to put each view in a separate nib and unload
    it when not in use. But in some cases the view to use depends on the
    selection in the master list, therefore the used view can rapidly
    change when the user iterates through the master list. I would
    therefore prefer to keep the views in memory once loaded.

    I do not expect real performance problems in the case at hand, but
    nevertheless I do not like the idea of a lot of useless activity
    taking place.

    Thanks
    Kai
  • on 12/16/07 3:43 AM, <kai...> purportedly said:

    > Is there an (easy) way to disable the bindings in the currently
    > unused views? To my understanding these bindings stay live and eat
    > CPU cycles even while a container view with the bound controls is not
    > installed in a window.

    AFAIK, binding do not do anything--i.e. do not consume any cycles--until
    something changes. There is no "active maintaining" necessary. Its all
    trigger-based.

    Best,

    Keary Suska
    Esoteritech, Inc.
    "Demystifying technology for your home or business"
  • > on 12/16/07 3:43 AM, <kai...> purportedly said:
    >
    >> Is there an (easy) way to disable the bindings in the currently
    >> unused views? To my understanding these bindings stay live and eat
    >> CPU cycles even while a container view with the bound controls is not
    >> installed in a window.
    >
    > AFAIK, binding do not do anything--i.e. do not consume any cycles--until
    > something changes. There is no "active maintaining" necessary. Its all
    > trigger-based.

    Sure, that's my understanding, too. But in a master-detail setup, the detail bindings are to the selection of the array controller. So all these bindings trigger whenever the array controller selection changes. That is, whenever the user changes the selection in the master list.

    Best
    Kai
previous month december 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today