What'ss more rare? Memory or CPU-time?

For a new project I'm starting to work on I asked myself (and am now asking you *g*) if I should optimize the scripts for using less memory or less cpu time. What is more rare, what lets a script run more smoothly and what causes less lag?

For example I have a couple of string and integer variables in a script. If I put them into a list, they'll eat up very much more memory then if I put them into a (looong) string. A list would be easier and I guess a lot faster to read from using llList2Integer and llList2String. On the other hand, if I'd use a string, that would safe a LOT of memory but be slower to process (calculate start and end positions in the string, padding integer values with zeros and so on).

Before I start test series, does anybody maybe already know the answer?

I'd go for saving cpu, and using memory.

Though even before both of those, I'd go for clean, understandable code.

Over time, the thing that will likely improve with no maintenance work on your part is the cpu it uses (as the scripting language becomes more efficient, maybe even compiles!)

The memory could improve too, also due to efficiencies. But you've got 15K or so to work with now, and if you're not up against that wall, I wouldn't sweat it too much. Though you might search the forum for efficient ways to add things to lists (which are not intuitively obvious...)

But if you write messy, hard to understand and hard to maintain code, it never gets better.

Rj

"Premature optimization is the root of all evil" -- Sir Tony Hoare

It all depends on what you are doing. If what you are doing is going to be memory intensive, then focus on memory optimizations. If what you are doing is going to be CPU intensive, focus on speed optimizations. If what you are doing is both memory AND CPU intensive, then you will probably end up focusing on memory optimizations somewhat, which is due to the fact that LSL is presently more limited by memory constraints than on CPU constraints.

If you don't know yet which it is, then go write something, then come back if you still aren't sure.

If it's literally just a couple, you've wasted more time posting the question than it's worth. But, since you then say a long string, I'll assume you're just being a bit sloppy. This is where the premature part of the Hoare quote comes into play: Until you can do quantify these better than "couple" and "long", it's premature to even ask the question. While there can be rules of thumb that can be applied generally, in most cases there is a break-even point between two choices, and that's where the quantification becomes necessary. In addition to knowing how much data, it's also important to know how often it's going to be accessed.

The quantification doesn't have to be terribly precise, just in terms of orders of magnitude. Are we talking ten values? A hundred? A thousand? Are the strings likely to be 6 characters long? 60? Is the computation for getting at the data going to be called every time it's used? On rare occasions? And so on.

I was dealing with this issue yesterday. I have a tool in beta that makes shapes out of bezier curves. I originally wrote it so that the points along the curve are calculated and stored once in a list of vectors. This seemed natural and tidy, since the points are used in two different places, and frankly I'm not used to 16K. Then a tester used a larger number of segments for the curve than I anticipated and boom, it runs out of memory. To avoid having a fixed max number of segments, I changed it so each pair of points is calculated as needed, rather than stored. The calculations are duplicated now, but it turns out not to effect the real speed of the app because of delays related to rezzing and messaging.

My point is that I think it really depends on what you're doing, and possibly on decisions about tradeoffs that have no right or wrong answer.

Scripts are limited to 16K of memory, for instructions, stack, and data. If you can get done what needs to be done in that amount of memory, then optimize for speed because otherwise you're simply wasting any unused memory.