I have an app that has a parent and two distinct child apps (lets call them ChildA and ChildB) of which there are likely to be multiple instances of each.
For code efficiency I've placed all common functions in the parent and then call them from the child. For big functions that have few calls that makes sense and probably has little effect on speed. But for small functions that have many calls, I'm wondering if there is a performance penalty in doing it this way.
The other option is a library which I understand basically merges the library with the app code so that called functions appear to be 'local' to the app.
There is some cost incurred by parent/child calls (it involves waking another app or driver), but how much that matters in real use is probably negligible for most code. If your app frequently runs and does this a lot, maybe you'll want to give some consideration to it. App Stats and Device Stats under Logs are probably the best objective measurements you can get.
Regardless, a library is certainly an option. The library code is merged at the end of the "original" app (or driver) code when saving, and the hub works with the "full" copy after that--which seems consistent with your understanding.
Tough to say as it's based on events but each event would cause the app to refresh the status for multiple devices (up to 10) and each of those could invoke 20 calls to the parent for string manipulation functions. So maybe 200 calls per event. The parent could also have 10 or 20 children so the numbers add up quickly.
I tried an experiment last night taking all of those calls that are invoked by the event driven model and moved those to the child. Those calls used by the parent\child UI I left in the parent. Although I don't have much hard data the device stats look a bit more balanced. Prior to that the parent app looked like a big hog with huge numbers of calls.
So I think that it the balance I'll go with. Calls invoked by the event model go in the child. Calls only invoked in the child UI go in the parent.
