Help to convert llWhisper to llMessageLinked

I have a problem which is that my original design for a game works well but needs performance improvements. One step I want to take is to convert all the llWhisper commands on private channels to llMessageLinked commands.
Not really a problem just a lot of work, you say, I agree but the problem is in the debugging of the changes. My original scheme uses a separate object which listens to the llWhisper commands on the private channels and says them to the owner.

How do I monitor the llMessageLinked output?

I could parallel each and every llMessageLinked with a llOwnerSay but this busts the 16k memory limit in 5 or 6 of the linked 135 prims.

Suggestions please.

Unless I'm missing something in your question all you have to do is implement a link_message event handler in the same script/another script in the same object.

Indeed you are correct another script with a link_message handler would work but would require it to be in a prim which is the target of all the llMessageLinked commands. Currently the llWhisper commands are all sent to specific targets to reduce load on the server by filtering. Therefore the llMessageLinked would similarily need to be targetted at specific prim/s.
Unless you know of a way to target a llMessageLinked at certain prims from a selection I don't think thisa will work.
This is the difficulty which I hoped to find a way around.

Thanks for the input, appreciate it.

How are you filtering the whispers? A separate listen channel for each prim? Or encoding it in the command, and having each target create one or more listens for each possible command it could accept? And do you ever send commands to multiple prims at one time from one point in the code?

llMessageLink can be targeted to a specific prim, using the prim number, but you'd have to know the number or numbers at the call site. If your model calls for sending commands to a list of prims at one time, then you could create a separate debugging prim that is always put into the list. If that's not the way the code is structured, then instead of calling llMessageLink directly from multiple locations, create a single function that looks like:

    SendLinkedMessage(string text, int prim) {
        llMessageLink....
        if (DEBUG) { llOwnerSay(text); }
    }

Of course, you'd then need to deal with the problem of setting or unsetting the flag.

Yet another approach could be to use a flag that would cause the code to send to all prims instead of just a specific prim, and add a prim that just listens and echoes messages.

Finally, the most obvious thing to do is to just test this on a very small scale, say 3 target prims, but test it to death. That will get the code working functionally, then remove the debug code and deploy to the 135 prims. It won't test the scalability, but having the text of the messages isn't as important for that purpose.

No. A large number have multiple listens.Yes.Yes.
Yes. There is already a master listen which is within all prims which would provide the DEBUG On/Off switch command facility, so this suggestion is viable. The question would be is the filtering in the individual scripts going to cause all the scripts to be listening andf filtering at the same time causing enormous server overhead and slow down the process. Remember the purpose of the rewrite is to improve performance.
Perhaps I have misunderstood your proposed method could you expand a little on it?Yes but the same argument applies.A good suggestion but because of the massive interaction between the prims it is not viable to try the subset principle as a whole. It would need to be employed for sections at a time.
I keep hitting the limit for code in most of the larger scripts which is one reason why there are so many. Perhaps this reqrite should be deferred until we got MONO when it is rumoured we will get more to play with.