|
|
Detecting changes within structures on input ports I have patch that builds a large NSMutableDictionary and publishes it to an output port. It modifies the contents of that mutable dictionary as time goes by. I have a second patch that receives that dictionary on an input port. That patch never sees the changes within the dictionary, until I reassign the dictionary to the output port of the first patch. I'd like to have the changes that the first patch makes, show up instantly within the dictionary the second patch receives, without having to reassign the output port constantly. If I do reassign the output port constantly, the CPU utilization goes up more than I'd like. How can I accomplish this? Thanks!
|
Well, the first thought that comes to mind is, that, usually, if a patch is designed that way, it's because it's analyzing a structure that isn't going to change much, or at all. An example of a patch that makes sense to design this way is the Directory Scanner - it searches folders, and returns a structure that often won't change in the course of a use session. It makes sense for it to build the structure once and not every cycle, or have a "refresh" button to make it build the structure again if needed.
If the patch is doing something like that, it may make sense to keep it the same. CPU spike would be expected when that kind of object evaluates again.
It sounds like you're constantly pulsing the refresh though... does the code of the plugin have something in it linked to your refresh boolean, to cause the plugin to re-evaluate/reload the initial structure? If so, the solution may be as simple as removing that to have the output structure update every cycle, when a patch is connected to the output. Hard to say for sure without looking at it.
The first patch isn't polling for updates based off a boolean input. It's receiving information over the network through a UDP listener. That information is normally coming in frequently (1-30 times per second). Each time an update comes in, the mutable dictionary is updated, and right now, the mutable dictionary is assigned to the output port each time this happens.
So, I'm not exactly pulsing the update, but it's happening constantly on it's own. My hope was that the first execution of the first patch, it would set self.outputStructure to the NSMutableDictionary that was getting constantly updated, and that the second patch with the inputStructure would be able to detected any changes in the NSMutableDictionary with no further updates of self.outputStructure by the first patch. Right now, I assign self.outputStructure to the same (but possibly updated) NSMutableDictionary in every cycle. This adds some overhead that I don't want. It seems that QC does some form of serialization an deserialization of the NSMutableDictionary when it passes it from the the output port of one patch to the input port of another patch. I expect that's the case because of the increased CPU load, and because the receiving patch sees all NSArrays that were nested in the output dictionary as dictionaries.
Is there a way to make the second patch see the updates every cycle without having to reassign the self.outputStructure to the same NSMutableDictionary every cycle?
Adam
I'm trying to clearly understand the relationship between the two patches. It sounds like the relationship between the second patch and the first could happen with any second patch.
I'm unsure of the answer to this one, maybe someone else knows definitively? That said, I would look into seeing if you can control the execution of the first patch via making the patch an external provider, and making time mode "idle". I think that would achieve what you want, but caveat emptor.
You're probably right on about QCStructure handling when using QCPlugin. Behind the scenes, using QCPatch / the "skankySDK"/ private API, all structures fit into the "GFList" type, and by using this I think you may be able to get rid of some of the hit of shuffling structures between patches (probably not all?). I don't think it changes the structure type underneath you in the private api (if this is re:10.8, I have no clue, stuff may have changed).