Multi Thread or Single Thread Choices

I have a complicated combination prim. In the various sub-prims are multiple scripts.
I need to rewrite these to accomodate a change to MONO. The greater availability of memory in MONO makes it possible to combine some of these scripts in fewer sub-prims.
The action of the script/s is essentially single threaded. A player clicks on a sub-prim which causes it to communicate with other sub-prims and eventually causes some effect visible to the player. The next player is then prompted to make their move and the process repeats until an end position is detected.

By putting multiple actions triggered from an initial event into multiple sub-prims do I gain anything in the way of performance overall?

Example
1. P1 clicks sub-prim.
2. Causes change in alpha of the clicked sub-prim.
3. Causes calculation of the effect on neighboring sub-prims.
3.1 Calculation of neighbors of adjacent sub-prims
3.2 Calculation of next to adjacent neighbors of clicked sub-prim depending on state of adjacent sub-prim alpha.
4. Causes change of alpha in eligible adjacent sub-prims.
- Recursive step 3 until no more effects.
5. Waits for selection by P1 of one of the changed state sub-prims.
6. When selected reverses the alpha state of all the non selected sub-prims.
7. Prompts P2 to play.

Now this is inherently more than one thread 3.1 and 3.2 can be done at the same time with communication between them.

Putting all the scripts for 3.1 and 3.2 in a single prim would force them to be serialised.

Is there any advantage in NOT doing it?

If it is working the way it is I would not bother to rewrite it, just recompile it. The execution will not become faster by serializing the code, on the contrary. The load on the SIM might become lower, but you can't even measure that (yet).

I'll echo what Dora said and add that I would not invest any time on a rewrite until the tools hit Aditi to measure memory usage and we start to get some clear indication as to what the guidelines are going to be.

Thanks to both you and Dora for the words of wisdom. One little problem, I am waiting for a solution to the error which results after recompiling under MONO. I therefore am taking the time to recheck the code which works happily under LSL and while doing it I thought I could speed things up some more.
NOT yet appears to be the consensus.
Will we ever be able to create multi threaded scripts which run in parallel?
Just an idle thought.

just going off of your description, breaking the some or all of the recursive nature into one based on directions you process each direction of affecting changes in different scripts, allowing a little bit of parallelism. fwiw lsl doesn't do recursion so well (although if the recursive function can be crammed in it's own script, as opposed to being internal to a script that'd probably help.

FTR, if it ain't broke...

Technically you already can. If a link message triggers events in two scripts, those two scripts will run in parallel. I use this structure in most of my products, as do many.

Point well made but that is just the point it is broke.
Recompiling the scripts that work under LSL in MONO does not work the communication aspects between sub-prims does not work and the rezzing of new sub-prims fails to be reported.
I am quite happy to ignore the parallelism absence, and the recursion is more like iteration. It would be nice to think that at some point we could include modules other than those generated by MONO e.g. Haskell or ML to handle the recursion but pigs will fly before that happens.

yeah, but we keep trying to glue the wings on anyway =)

I meant if it works in LSO, keep it there for now, at the very least ontil your mono bugs get resolved, or workarounds are available... no sense beating your head against the wall (well any more then you already have to with LSL in general)