User talk:Omei Qunhua
An appeal:
When submitting sample scripts (or editing existing samples) PLEASE ensure you've tested the resulting script. There can be no excuse for blindly editing and not testing, and certainly no excuse for submitting scripts that won't even compile! Omei Qunhua 09:02, 9 December 2012 (PST)
- I wholeheartedly agree. I have been guilty of the sin but I agree. lslint and lsleditor are our friends. I noticed you mentioned that some edits have been breaking examples. If that happens, please make a note of it somewhere, we need to keep track of this so we can halt any negative trends. -- Strife (talk|contribs) 08:34, 14 December 2012 (PST)
- Well if you want to observe a negative trend, the following Wiki pages / examples were all corrupted by the same person :)
Wiki Page Date Corrupted Nature of Error Gun Script 18-Oct-12 Compile error llGetAgentList 8-Dec-12 Compile error llGetAgentList 9-Dec-12 Run-time bad results llDialog 24-Sept-12 Compile error 11SetLinkAlpha 30-Sept-12 Compile error llGetLinkInventoryPermMask 25-Nov-12 Compile error llResetOtherScript 24-Sept-12 Run-time error llGetSimStats 8-Dec-12 Compile error llRequestURL 24-Sep-12 Compile error llSetKeyframedMotion 24-Sep-12 Run-time error llEvade 4-Dec-12 Compile error llGetClosestNavPoint 4-Dec-12 Compile error llGetNotecardLine 23-Sept-12 Run-time bad results StringIsNum 7-Oct-12 Compile error Sensor 28-Oct-12 Compile error and Run time wrong results
(I've also corrected 4 other non-compilable or faulty example scripts by other editors, where the errors have existed since July 2012, March 2008, and Sept 2007)
Omei Qunhua 15:26, 18 December 2012 (PST)
- I have take a look at all his changeings in the example scripts and do not agree with the most, Everywhere he remove inside the sub-if's the clamps and resort the events. The most of the experienced scripters do not realy read it, but for beginners i think its bad when they not see where are the clamps necessary and where not. Daemonika Nightfire 10:19, 20 December 2012 (PST)
- I disagree with the way you say a script is "faulty" You do not clearly state your reasoning which is debatable because it's based on your own personal preference. --Ackley Bing 10:12, 14 February 2013 (PST)
- It's not a matter of "personal preference". If a script doesn't compile, or gives wrong results at run-time, then it's faulty. Omei Qunhua 03:22, 15 February 2013 (PST)
More size constructs
I've confirmed your results and made a few more tests of size optimization constructs.
x=-~x; 6 bytes (equivalent to ++x) x=~-x; 6 bytes (equivalent to --x) y=-~x; 6 bytes (equivalent to y=x+1) if(~x); 7 bytes (equivalent to if(x!=-1)) x*2; 8 bytes (equivalent to x<<1) x=-~-~x; 8 bytes (equivalent to x+=2) x=~-~-x; 8 bytes (equivalent to x-=2) y=x+1; 10 bytes x=x*2; 10 bytes (equivalent to x=x<<1) x*=2; 10 bytes if (!~x); 10 bytes (equivalent to if(x==-1)) if(x&0x80000000) 12 bytes (equivalent to if(x<0) for integers) if(x<0); 13 bytes x=x<<1; 14 bytes if(x!=-1); 17 bytes
For float x:
x=0; 9 bytes x=0.0; 12 bytes
For vector x:
x=<0, 0, 0>; 27 bytes x=<0.0, 0.0, 0.0>; 36 bytes x=ZERO_VECTOR; 36 bytes
for list x:
llGetListLength(x); 40 bytes x!=[]; 13 bytes (note: only list LENGTH is compared - actually subtracted. That returns 0 for empty list.) x==[]; 13 bytes if(x==[]); 17 bytes if(x!=[]); 17 bytes x!=[""]; 23 bytes (note: only list LENGTH is compared - actually subtracted. That returns -1 for empty list.) x==[""]; 23 bytes (true if x has 1 element) x!=[[]]; 23 bytes (list may not contain lists but this is allowed?!?!) x==[[]]; 23 bytes if(x==[""]); 27 bytes x!=[1]; 28 bytes (true if x has 1 element) if(x==["","",""]); 47 bytes if(x!=["","",""]); 47 bytes if(llGetListLengt(x)==1); 53 bytes if(llGetListLengt(x)!=1); 56 bytes if(x==["","","",""]); 57 bytes
Some of those may be worth being included in LSL Hacks, which I'd say is the place for code size optimization. Your list results are run time size related and thus worth being included as an update to LSL Script Memory. --Pedro Oval 09:35, 29 December 2012 (PST)
- Wow some of those are really interesting. I would venture the reason float zero is so expensive is how it's being encoded (there are several ways to encode floats in IL). They haven't optimized the zero case. I'm very surprised that x * 2 is less than x << 2. -- Strife (talk|contribs) 13:28, 29 December 2012 (PST)
- Well try these for size ... x+x; 4 bytes, x=x+x; 6 bytes, x=x^x; 6 bytes. Food for thought! Omei Qunhua 06:05, 30 December 2012 (PST)
- VERY interesting, thank you!!! --Pedro Oval 12:11, 30 December 2012 (PST)
- Well try these for size ... x+x; 4 bytes, x=x+x; 6 bytes, x=x^x; 6 bytes. Food for thought! Omei Qunhua 06:05, 30 December 2012 (PST)
Some more interesting results (all for LOCAL variables) [WITHDRAWN - SEE BELOW]
integer a; 49 bytes integer a=0; 53 bytes string a=""; 53? 55? bytes (I'm unsure if there's a preexisting instance of "" or not - my measuring method can't tell) string a; 53? 55? bytes string a="a"; 53 bytes plus 2*(num characters+1) per each different string (equal strings are referenced just once) float a=0; 54 bytes list a; 55 bytes list a=[]; 55 bytes float a; 57 bytes float a=0.0; 57 bytes key a=""; 60? 61? 62? bytes (same problem as string) key a="string"; 60? bytes + 2*(num_characters+1) per each different string
Braces don't seem to add anything: {integer a;} occupies the same size as integer a; and so on. Since the string case is complex, let me put an example. string a="aaa"; string b="aaa"; will use 53+53+2*(3+1)=114 bytes, because the string is the same in both cases and it's reused, but string a="aaa"; string b="bbb"; will use 53+53+2*(3+1)+2*(3+1)=122 bytes because the strings are different.
I'm getting inconsistent results with the keys. Something else seems to be going on. I get 61 bytes sometimes and 60 others. Wonder if there's a byte alignment problem. If so, that could make some of the previous measurements incorrect, even if they looked consistent. --Pedro Oval 13:40, 29 December 2012 (PST)
- Using the measurement method you suggested (or perhaps a variation), I have determined that an empty string uses 6 bytes always, while a 1 or 2 character string uses 10 bytes for the first appearance and 6 for the rest, and a 3 or 4 character string uses 14 bytes for the first appearance and 6 for the rest. Further testing suggests that string constants in code are allocated 4 bytes at a time.
- The previous results for local variable declarations can't be considered reliable. With this measurement method I get many variations for keys and strings: 132 bytes for the first appearance of
key x="", 56 for the second, 66 for the third... and also crazy for strings. I just withdraw the results. With integer I also got inconsistencies.: 43 bytes when measured with this method. What seems clear is that there's one implicit assumption wrong and I don't know which one or why. I guess a better understanding of CIL would help me interpret those results. Not sure if I'm willing to dive into that though. --Pedro Oval 14:44, 1 January 2013 (PST)
llGetSubString
I obviously did not review that edit! wtf were they thinking? Thank you. -- Strife (talk|contribs) 23:08, 3 January 2013 (PST)
UTF-8
UTF-8 characters can be more than 2 bytes, by the original standard, used by LSO, they can by 5 bytes. UTF-8 supported by Mono supports up to 4 bytes per character. -- Strife (talk|contribs) 20:31, 14 January 2013 (PST)
- Yes I know. That's why I quoted an example of a 2-byte UTF-8 when giving 512 as a UTF-8 limit. I didn't want to go into a full explanation on every page. Just wanted to give some clue that 1024 bytes doesn't necessarily give 1024 characters (and an opportunity to correct the 1023 to 1024). Maybe a link to a page on UTF-8 would be appropriate. But I think the current UTF-8 page needs overhauling. It starts by saying "SL uses UTF-8 for storing and transmitting strings" which I think is no longer always true (i.e. storage in Mono) then the UTF-8 page gets hijacked with complex code examples concerning Unicode which maybe appeal to 0.1% of Wiki's users. We need to sort the basics out on SO MANY Wiki pages, before leaping into hyperspace. And that's been the impetus behind my sudden burst of editing activity over 5 weeks. (IMHO, LOL) Omei Qunhua 00:26, 15 January 2013 (PST)
Wiki editing
I'm not sure why you feel the need to insult other editors with every other edit summary but I wish you all the best and merry christmas. Hopefully you can find some time to loosen up during the holidays. Best regards -- Kireji Haiku 14:29, 19 December 2013 (PST)