Please compare these two script bits

I'd like to know about efficiency with the following two choices.


The new one below:::

    listen(integer channel, string name, key id, string message)
    {
        llGetOwner();
        if(message)
        {
            //string llGetSubString(string src, integer start, integer end);
            list locs = llParseString2List(message,["|"],[""]);
            //llOwnerSay((string)locs);
            crate_pos = (vector)llList2String(locs,0);
            crate_rot = (rotation)llList2String(locs,1);
            list locs2 = [(vector)crate_pos,(rotation)crate_rot];
            llOwnerSay("Position" + (string)crate_pos + "Rotation" + (string)crate_rot);
        }
//example is the object being queried, and the result sent to me, is  <129.750122, 132.092316, 699.780945> <0.000000, 0.000000, 0.000000, 1.000000>.. I also get the result using another ownersay via touch_start.

            
    }

with the above, it seems to work good, but at first, it seemed to only return the result in say. I had a duplicate llOwnerSay message in touch_start that only returned null <0,0,0> values.. I've made several new prims and have been unable to duplicate what I thought was a problem, it's working as I expected now. Any reasons why, it's possible I changed a slight bit of coding and didn't notice, but if someone knows why this might fail, please explain.


Before i started using lists(out of lack of know-how) I used the following:

//the object queried had 2 llSay commands llSay(1,pos) and llSay(1,rot) one after the //other.  It would speak when asked to, and the information was processed as you see //below.(mind you I know this isn't the most efficient, but it worked.  I'm trying to improve //by posting.  ^^)



listen(integer channel, string name, key id, string message)
    {
        if(message !=NULL_KEY)
        {
            mylist += [message];
            if(llGetListLength(mylist) == 2)
            {
                llSetTimerEvent(4);
            }
        }

I never see the above method used anywhere else, but it worked - and never failed me once. Is it not used because speaking in a channel twice is more laggy, or is there another reason?

I would favor the first way, I just don't trust the chat system enough to listen for 2 messeges back to back and expect them to come in any sort of predictable order.

Yeah. With the second approach, even if llSay() order is preserved for one source, if one ever had more than one of the "llSay-ers" active, the listener could very easily get confused, unless one used a more complex list(s) structure to keep track of which key said what, and then trigger further processing when one of them said both pos & rot... which would be a lot of extra work.

As-is, from a pure efficiency standpoint, I doubt if it makes much difference because llParseString2List uses some processing, too... although probably a bit less apt to fragment heap than the list append of the second approach. (That's ignoring all the stuff that derives "locs2" in the first version; presumably the second approach, too, would want to end up with a list of vector and rotation, eventually.)

There are a few oddities in the scripts, though. The first one has a stray (or superstitious?) "llGetOwner();" call, and both seem to be testing the string "message" in an unusual way: the first as a boolean integer, and the second as a key. Not sure what those tests are trying to guard against, but they look pretty suspect to me.

Ah, this wasn't a complete script at the time, just part of some tests. I had actually cut and pasted a couple areas to get the whole part.. so ya, there's going to be some odd things as well as it probably wouldn't compile straight up. The actual script works in world, and as per advice, I've decided to go with taking the big rock and smashing it into smaller rocks approach. Thanks for the replies