Respect to the real scripters!

my hats off for those memory hogging multi scripted items

running into the wall with 15.8kb memory usage at startup after doing some http calls to learn the hardway and rewrite everything into linked mesages so the mem hogging buggers can be reset for another pass after getting loads of stack-heap errors


/me makes a note to have a memory check in the main scripts from now on (i know, not reliable but when it says 15kb at startup you know enough...)


edit: real should be "real", it`s easy to make a signle script but there`s ALOT more work to do multi scripting to avoid the heaps when working with large complicated scripts that need sub scripts just to do the proccessing so no offense to anyone

cya in 2009

LOL, don't worry, it gets easier. With my first scripts I had the same issue, you don't realize how quickly that 16k limit creeps up on you. And the first time you have to tear down and restructure can see unbearable. But in time it will be second nature. Welcome to the multi script club

lol thanks

a sleepless night and i`m allready done, took a couple of hours for a crash course to figure out how linked message works by looking at some examples in the wiki and using the 2nd parameter (num) to define each scripts acts on it`s own pre defined "channe"l set in all scripts

didn`t expect to have it done this fast

rewriting the http handler to work with the linked message system i kept it all in 2 states, default and state http, memory usage was still pritty high at around 13kb to where i`m currently at with the code

rewrote it again and placed all queries in their own state and then just the main http state to grab, check, proccess the return and then send it to the next query state and the memory usage went down to 12.58kb?

same query code, just instead of in 1 state, cut into several states of it`s own and http state left unchanged

edit: moved this question to the memory tricks thread
also for a joke i removed my debugging routine
global:
integer DEBUG;

in the code:
if (DEBUG) llSay(0, "state :: 1.3";

have like 16-18 in the script but with just removing them, memory drops to 10.18kb from 12.58???

any idea what the heck is hogging memory with that simple statement?

In the absence of better scripters, let me hazard a guess that IF your debugging line was the only print statement in your code, you eliminated LSL's text formatting library routines when you got rid of it. In any language, formatters are memory hogs, requiring buffers and tables to do their work.

Strings seem to take up a deceptively large amount of memory. Each of those debug messages is 12 characters long, however, you can go here to see how much memory each uses. http://www.lslwiki.net/lslwiki/wakka.php?wakka=MemoryUsage

A string takes up 18 bytes plus the number of characters, so each of your debug entries was around 30 bytes just from the string data alone, not counting opcodes for the IF statement and calling a function.

that isn`t the case, have several llSay()`s in that script, but, it will be an interresting idea to try with moving the debugging and llSay() to the proccessing script to save extra memory if it works in the http handler


hmm this all explains why memory went down aswell from cutting code from if statements to their seperate states for easier access by my linked message handling for this script

got some new ideas to try now, thanks

turning into a memory freak
maybe some day i`ll get to be a scripter lol

I've been doing this for a year and a half, and I've written all kinds of scripts from vending to security to movement to...well, you name it. I'm STILL agonizing over how to shuffle a deck of 200 or so cards. LOL. At this point I'm planning on using a seed and a manually implemented pseudo-random number generator. Weeeeeeeee!

Anyway, the point is, don't feel too bad. 16kB is utterly ridiculous for the kind of applications you get into after graduating from simple chat scripts. Especially given that SL decided to use absolutely horrible list storage and a fixed 2-byte character encoding. Just keep praying for Mono, and don't let the bits, bytes, or pies get you down.

oh yea i agree, 16kb is filled with easy when making a bigger app then the normal scripts and get a headache from stack-heap errors out of no where untill checking memory usage lol

using tips&tricks from the memory tricks thread and with splitting some code into several script, the hogger is down to 11.74kb where it would have returned a heap error at the same stage leave the debuging in it for now while rewriting


love these forums, i`d be stuck without you all!

moving repetitive code segments into to functions reduces memory overhead, but increases slightly runtime...

if(DEBUG) llOwnerSay( "stuff" );

runs faster but takes more memory (on repeated calls) than

checkDebug( string msg ){
if(DEBUG) llOwnerSay( msg );
}

checkDebug( "stuff" );

....

anytime you find yourself repeating a block of code it's almost always better to load it into it's own function or find a way to do it more efficiently so the block only has to be written once...

that isn't to say a single statment or two can't be repeated, but if you find yourself repeating a single complex statment frequently make it a function if it's feasible

/me gets an headache from cross posting

thanks everyone

think it`s time to have this thread die and leave it for the memory tricks thread so anyone can readup on problems and solutions regarding memory issues

side effect of working up from the bottom of unread posts... keeps the order but tends to catch the least responded to post of a set first

llDie( thread );