Talk:LSL Function Style/Celierra Darling

Complexity is irrelevant. LSL functions delay seemingly random amounts, and functions you'd think would be CPU intensive like MD5Sum ... aren't. There's so much crap in terms of energy and delay and other random throttling on top of the function that a complexity rating would be meaningless, and potentially lag-inducing. Someone might avoid an n^2 function and implement their own nlogn version in LSL, which would undoutably be very much slower and cause more lag. Built-ins are always better than implementing the algorithm in LSL itself. Gigs Taggart 21:51, 23 February 2007 (PST)

List & string functions tend to have a high complexities as all the parameters have to be copied onto the stack. Most of the effects observed in LSL are related to the VM. With Mono, the true effects of complexity will be apparent (because Mono runs faster). Strife Onizuka 09:25, 24 February 2007 (PST)

Yes, but should we include it in the meantime? It looks like you agree it's currently misleading for the same reason I think it it. Gigs Taggart 09:05, 26 February 2007 (PST)

Well it's hard to say really, I don't think anyone has ever done a complexity comparison between parameter loading and function runtime. It's hard to say which is the dominant effect. Though something against it's inclusion is that all but a small handful of functions are excluded from the OS client source; so most of the values would be unknown. I'm more inclined to leave something in that would be interesting and have it not used then not to have it at all. It is easy enough to remove it or hide it where it is not used. Thinking about adding it to my templates. Strife Onizuka 13:52, 26 February 2007 (PST)