Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: Q, in this case, I disagree. Changing the SCRIPT_MEMORY reports later will not technically break content, it would just requires to slightly alter the interpretation of it. Modifying the cap variables for event(s) to lower You never worked in customer support, did you? :P Understandable view on your side... but the facts that some people don't have the proper judgment or skills to rely or analyze statistics accurately, shouldn't be a reason to deprive those who can use it properly as well as ethically, with valid and useful reasons for doing so. Even people who know what they are doing can't do anything with the numbers reported. You don't know how much memory a Mono script uses, so it's of no use to you how many scripts there are inside an object. The avatar with 200 scripts on them might actually use less memory and CPU time than another avatar with 20 scripts on them. Unless we get *proper* metrics on cpu time and memory consumption, all this talk about script conut and memory is utterly useless and will only confuse people and lead to drama. Zi ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
On Sat, Oct 2, 2010 at 4:43 AM, Zi Ree tinacl...@gmx.de wrote: Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: Unless we get *proper* metrics on cpu time and memory consumption, all this talk about script conut and memory is utterly useless and will only confuse people and lead to drama. There is right, and there is soon. A function that returns the number of scripts is not *wrong*, and it sounds like it should be easy. The right functions will take longer. Adding better functions later does not break any content. Don't let the perfect drive out the good. lee ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
Am Samstag 02 Oktober 2010 schrieb Ponzu: On Sat, Oct 2, 2010 at 4:43 AM, Zi Ree tinacl...@gmx.de wrote: Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: Unless we get *proper* metrics on cpu time and memory consumption, all this talk about script conut and memory is utterly useless and will only confuse people and lead to drama. There is right, and there is soon. A function that returns the number of scripts is not *wrong*, and it sounds like it should be easy. The right functions will take longer. Adding better functions later does not break any content. Don't let the perfect drive out the good. lee phoenix already does that, in its radar you can define a warning that tells you when the script count in the sim changes by more than a threshold that you define... so there already _is_ a way to count all scripts in a sim. bye, LC ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
THANK YOU, what he said. Why lie and make up some weird inaccurate number to leave people guessing, just give us a script counter, LOL. From: Erik Anderson eri...@odysseus.anderson.name To: Bryon Ruxton br...@slearth.com Cc: opensource-dev@lists.secondlife.com Sent: Fri, October 1, 2010 9:05:41 PM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request I hate to break in like this, but we're discussing how inaccurate it is for Mono scripts to contribute a different multiple than LSL scripts, but in the end aren't we just counting scripts? Would it be more accurate to report a script count and let the user do whatever multiple they want, and then later when there's a better number out there for memory usage release that as a new number? If any assumptions are made by the scriptor at that point they know where the accuracy lies... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Platform specific static quick download links to latest installers
Shortened quick links: http://bit.ly/viewer-dev-latest-Linux http://bit.ly/viewer-dev-latest-Mac http://bit.ly/viewer-dev-latest-Windows All results: http://bit.ly/viewer-dev-latest On Thu, Sep 23, 2010 at 2:59 PM, CG Linden c...@lindenlab.com wrote: The links are now active. -- cg On Thu, Sep 23, 2010 at 2:09 PM, CG Linden c...@lindenlab.com wrote: Linux: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/arch/Linux/quicklink.html Mac: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/arch/Darwin/quicklink.html Windows: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/arch/CYGWIN/quicklink.html Those links will start working once TeamCity cranked out a new build. -- cg ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
On Sat, Oct 2, 2010 at 12:34 PM, miss c miss_c...@yahoo.com wrote: THANK YOU, what he said. Why lie and make up some weird inaccurate number to leave people guessing, just give us a script counter, LOL. what i would suggest is 1 have a way to see TOTAL scripts LSL scripts and Mono scripts 2 if any ARC type number is used then guess LOW 3 figure out ways that can be found to make scripts obsolete (skirt sitter and resize scripts are the Low Hanging Fruit on this one) -- Robert L Martin btw could somebody please set the Reply To: flag correctly??? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] TCMalloc Memory Profiling?
I saw the memoryprofiling debug option to enable the TCMalloc's memory profiling. Reading up on it here http://goog-perftools.sourceforge.net/doc/tcmalloc.html Will this enhance the performance of my viewer or is this legacy? If it will enhance it, why is this option not on by default? Can someone enlighten me please? Thank you Miss ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] TCMalloc Memory Profiling?
On 10/02/2010 09:57 PM, miss c wrote: I saw the memoryprofiling debug option to enable the TCMalloc's memory profiling. Reading up on it here http://goog-perftools.sourceforge.net/doc/tcmalloc.html I guess you're talking about the MemProfiling debug setting? (When talking about less well known debug settings, please always mention their exact name to avoid confusion. Sometimes there are several similar ones.) Will this enhance the performance of my viewer or is this legacy? While I don't know what that option does exactly, it sounds like it doesn't choose which library to use for memory allocation, but rather enables profiling *if* the used library is TCMalloc. I don't how TCMalloc usage would be enabled, but I guess that'd be a compile time option, not a run time one. While the usage of TCMalloc might make things faster compared to other malloc implementations, enabling /profiling/ (presumably: measuring how many allocations happen where and when in the program) is more likely to slows things down. If it will enhance it, why is this option not on by default? Can someone enlighten me please? According to http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html , their heap profiling (which might well be what the debug option toggles) can be useful for * Figuring out what is in the program heap at any given time * Locating memory leaks * Finding places that do a lot of allocation This means it's mostly interesting for developers who are either debugging something and thus want to see what happens in the memory they've allocated or who are hunting memory leaks or other reasons of extensive memory usage (or rapid allocation/deallocation cycles, etc.). I don't think enabling it would directly benefit the typical end user in any way. Cheers, Boroondas PS: There's lots off guesswork involved in the above, so anyone who knows more/better, please correct me. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
On Sat, Oct 2, 2010 at 4:40 PM, Argent Stonecutter secret.arg...@gmail.comwrote: On 2010-09-29, at 18:06, Kelly Linden wrote: * In the end the number of scripts shouldn't be important. I have lofty desires to remove the arbitrary limit on script size so that we can stop the silly games of splitting scripts apart because you need 10k more memory than the default. On the other side being able to declare that your script really only needs 4k would be hugely beneficial. At that point reporting the reserved memory is more meaningful than the number of scripts. Could this be applied to LSL scripts as well, since they could be made potentially MUCH smaller? A kilobyte might be enough for a poseball, for example, and even less for a titler or particle script. Unfortunately no. LSL scripts take up 16k of memory no matter how much they actually use. - Kelly ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
