Diffing on subscription updates is fundamentally problematic

Sorry to pile on, since this project seems to've gone by the wayside, but if you should ever pick it up again, thought I'd leave a little note here.

I noticed that after updating from the debian-packaged copy of groovebasin to the (almost) latest (4.3.0), responsiveness declined significantly when sending commands to the server. Profiling shows that large chunks of time are taken up in diffing the previous subscribed values against the current values, when the data set is large. When initially scanning a large library, the 'library' key gets updated constantly, causing these diffs, and thus locks up the event loop so the application can't respond.

I'm not entirely certain what the purpose of this approach was; perhaps to enable clients to reconnect and get updates they'd lost? Or to account for consumers that can't keep up? Anyway, either shortcutting this operation when it's not necessary, or simply passing the information about what changed all the way up the chain, would take care of it. I couldn't think of any simple fix just looking at the code without a bunch of context.