Help ... Script Size in Mono

Just went to compile a new script, first time with new scripts in Mono. And when writing I thought, great 64k .. no way I'll overrun that ... yet it won't compile. Moved inline two functions that were only called once, but to no avail. The script has four states, four functions, and about 1400 lines (including comments and whitespace. Heavy used of declared global 'constants' especially to remove repeated usage of 'system' constants (Empty String, #1, NULL_KEY, etc). I cannot belive this is over 64k ... any pointers? (Script in follow-on post.)

... Well it will be when I stop getting errors saying I have no permission to reply <sighs>

... Seems the script is too long to post here unless I break it into multiple sections ... whats the limit?

//

// Name
//
// Description
//
// *******************************************************************
// This program is the intelectual property of Dreamscape Scripts,
// and is sold with a limited redistibution license. You may use this
// on your own, and as well it can be 'sold' as part of a build or a 
// designed item. It may NOT be sold as an individual script or part 
// of a package of scripts.
// 
// If you have paid someone other than Dreamscape Scripts or an authorized
// reseller .. contact me and I'll get you a authorized version ... and
// track them down inworld and harass them ;-)
//
// Writen by Shifting Dreamscape 
// *******************************************************************

I can see this easily being over 64kb.

1) Why create your own constants? Complete waste of memory for 100000% no benefit.

2) Why not break your script into separate scripts and use link messages? 1400 lines is a wee bit absurd.

3) Just because it maxes out at 64kb doesn't mean you can use sloppy code. MONO uses more space for the same code, that's why LL gave us more space. Optimize things and trim.

I'm tired, won't be able to suggest anything else without sleep first.

Arcane .. thanks for the comments ... and some response from my point ... (and sloppy code it is not, maybe too complex for LSL but not sloppy, have been writing code for over 20 years now)

The constants are to save memory .. For a string, empty string("" for example, the Global costs 19b while simply typing "" costs 3b. So if you have 7 or more places where its used, memory is saved. With integers it still seems to be reliable (with an exception that I'll cover below). Global Integer = 15b, Integer = 5b ... so if you use the number 1 more than 3 times it would use less memory to create the global, and for NULL_KEY, being 39b every time you use it, the savings are clear.

The one thing that makes me wonder is the entry in the Wiki that says '6 bytes to reference variables' ... what does this mean?

And as to breaking up, already have broke out unique functionality, and will see what else could be broken out, but for a clean design, with the functionality that needs to be there in each script, would not want to in less that is the only answer.

As well .. take into account that of the 1400 lines ... close to 40% is comments and whitespace.

Someone correct me if I'm wrong, but don't comments count as part of script memory usage? EDIT: Ok, I was wrong. It doesn't appear to.

There are advantages to breaking a large script up into smaller scripts that talk to each other. You can use the "modules" with other script projects. For my particle generator, I have four different scripts doing various things.

One thing I noticed about LSL (have not looked for MONO) was that your variable names also take up memory. So, if you use large or descriptive variable names it can be a memory hog. Another thing I did was move some of the frequently repeated text into strings to save even more memory.

It's a balancing act for sure, with a large project. I have been programming for over 20 years myself and I consider myself proficient at it. I'm not a math whiz and I optimize as best I know how, but I'm not an optimization freak. I like how the script langauge forces you to find new ways to tighten up your code. It exercises the programming muscles.

Frankly, I"m with Shifting on this one. 1400 can hardly be considered "absurd", it's fairly easy to get there with a non-trivial script. Not all scripts benefit from being "broken up" as that often adds needless complexity, i.e. the design of a protocol and breaking naturally linear code into a less obvious asynchronous pattern. Sometimes you may *need* modules, but in LSL and indeed most scripting languages genuine (not-cut-n-paste) re-use is more usually the exception rather than the rule.

Overall, I had also looked forward to the 64k hoping to gain bytecode space (2000+ line scripts) and many other benefits, none of which really panned out to the benefit of general script apps. The (later rewritten!) Mono information does point out that the major reason for increasing script limits to 64k was owing to the space required by the CLI bytecode. Bleah.

my 2c
/esc

Unfortunately, the reason they increased the memory limit to 64k is BECAUSE Mono bytecode and data structures take up about 3-4 times what the LSO code did. Contrary to popular belief it was not done to allow us a little more breathing room.

Thanks for the responses so far. So in the end it seems that I need to be as compact in coding in Mono as before ... ufff

Pretty much, yeah. Now Mono DID help (at least in many places) with performance, so you can relax a little about things like mathematical computation. Hopefully we'll even get some optimization eventually. Heh.

...however this was not as originally advertised. The wiki statements were rewritten mid-year.

Yeah, ran into same trouble with script size on my user interface project.