PRIM_LINK_TARGET efficiency question.

[Quistess Alpha]

So, I've heard (and it seems generally common knowledge) that making a single llSLPPF call using the PRIM_LINK_TARGET option to specify multiple links is more efficient than making multiple llSLPPF calls per request. What I'm wondering though, is whether multiple unnecessary PRIM_LINK_TARGET specifications degrade or affect viewer-side performance (or change the client-update message) much if at all. for example how would

llSetLinkPrimitiveParamsFast(0,
[
  PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 0, UUID, <1,1,0>,<0,0,0>,0.0,
  PRIM_LINK_TARGET, 3, PRIM_TEXTURE, 0, UUID, <1,1,0>,<0,0,0>,0.0,
  PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 1, UUID, <1,1,0>,<0,0,0>,0.0,
  PRIM_LINK_TARGET, 3, PRIM_TEXTURE, 1, UUID, <1,1,0>,<0,0,0>,0.0,
  PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 2, UUID, <1,1,0>,<0,0,0>,0.0,
  PRIM_LINK_TARGET, 3, PRIM_TEXTURE, 2, UUID, <1,1,0>,<0,0,0>,0.0,
  PRIM_LINK_TARGET, 2, PRIM_TEXTURE, 3, UUID, <1,1,0>,<0,0,0>,0.0,
  PRIM_LINK_TARGET, 3, PRIM_TEXTURE, 3, UUID, <1,1,0>,<0,0,0>,0.0,
  /*...*/
]);

compare to

llSetLinkPrimitiveParamsFast(0,
[
  PRIM_LINK_TARGET, 2,
    PRIM_TEXTURE, 0, UUID, <1,1,0>,<0,0,0>,0.0,
    PRIM_TEXTURE, 1, UUID, <1,1,0>,<0,0,0>,0.0,
    PRIM_TEXTURE, 2, UUID, <1,1,0>,<0,0,0>,0.0,
    PRIM_TEXTURE, 3, UUID, <1,1,0>,<0,0,0>,0.0,
  PRIM_LINK_TARGET, 3,
    PRIM_TEXTURE, 0, UUID, <1,1,0>,<0,0,0>,0.0,
    PRIM_TEXTURE, 1, UUID, <1,1,0>,<0,0,0>,0.0,
    PRIM_TEXTURE, 2, UUID, <1,1,0>,<0,0,0>,0.0,
    PRIM_TEXTURE, 3, UUID, <1,1,0>,<0,0,0>,0.0,
   /*...*/
]);

 

[Profaitchikenz Haiku]

What we don't know is how much optimisation of such calls is done when compiling, it could end up as-given or it could be re-ordered. If no re-ordering is done then we'd be able to do comparative timings but if the compiler is shuffling stuff around then testing wouldn't give any meaningful differences. For instance, if it reorders to your second example then both examples would appear to take exactly the same time.

Edited October 7, 2021 by Profaitchikenz Haiku

[Quistess Alpha]

1 hour ago, Profaitchikenz Haiku said:

is done when compiling

In my actual usage, the lists are generated at run-time. FWIW, which is really the only reason I'm worried whether it's worth trying to reorder it.

[Lucia Nightfire]

You would have to look at packet data to see if multiple PRIM_LINK_TARGET calls to the same link are stacked or if only end-result of all changes per link is sent in the packet.

A link's complete visual params "should" still be sent with full updates else doing tricks like updating invisible settext to force other visual prim param updating that previously failed due to packet loss or out-of-interest-list scenarios wouldn't be a thing.

It also isn't clear how the server "bundles" inputs either.

You can replace a texture UUID with an integer to force an error and the server will still update everything up until that error.

Intuition dictates trying to bundle calls by link and face as best as possible, though.

[Fenix Eldritch]

If nothing else, I suppose having fewer list elements to process might be more efficient, if marginally in this case.

[KT Kingsley]

Can it ever be more efficient to change everything and then unchange the things you didn't really want to change?

[Wulfie Reanimator]

12 hours ago, KT Kingsley said:

Can it ever be more efficient to change everything and then unchange the things you didn't really want to change?

Depends what kind of efficiency you're looking for.

From the script's point of view, obviously it would be more memory-efficient to change everything to the same thing and then replace a couple pieces, assuming that the replacements are fewer than the rest. It may even be faster within the script to do that if you're building the list(s) at runtime.

Whether that holds true on the server/viewer side when the call is made may be a different answer.

[Mollymews]

from the viewer pov it could be most efficient if it was ordered by texture uuid

if only that sequential calls to the same texture could mean less traffic/changeouts on the graphics card.  Dunno for sure tho. Would have to examine the viewer source code to get an idea how repeated calls to the same texture is handled