More Memory Questions

I would vote for SVC-835 if its title and description were changed to include island parcel owners as well. That is, gridwide, estate owners should have access to the "Top Scripts" tool, and should have a switch that would allow parcel owners/renters access as well.

I think some of the people who have commented on the bug would support that as well. As is, though, I find the bug title and description too limiting, and would not support LL spending resources on it. But I'm reluctant to change the bug title/description, not having been in on its creation. Meade, if you're reading this ....

I have virtually no on-the-job software design credentials, and I can conclude that, without intending to belittle anyone, many people optimize in the wrong way. Bitwise NOTs and clever byte-for-byte optimizations that in reality a good compiler should do for you are the last thing you really need to absorb, especially with Mono's speed at normal operations. If anything, they're somewhat useful for cutting memory usage, but even that is second to an understanding of your available data types and the best methods for representing your data. The real focus of optimization is improving your algorithms. A lot of this is discussed on this forum, which is good!

I still stick to my position that tricky LSL optimizations are mostly useless now, unless your script is THAT strapped for memory.

I agree with that completely. The idea behind the values of readability and maintainability is not that you CAN understand the logic, but that the code should speak for itself. It should be self documenting and say as clearly as possible what it does. With a few exceptions (the most common being API documentation and complex algorithm logic), you shouldn't NEED comments; they only offer redundancy and extra maintenance work. Bit arithmetic operators should generally be used where you specifically need to be doing bit arithmetic, not when testing for a special return value that just happens to be the ones complement of zero.

I agree with Hewee. However, I'd almost always like to see more comments about what a list will contain and how it's indexed (e.g., if a set of lists are indexed the same, say so.) Simply because LSL lets you put any type in a list, so the data declaration doesn't tell you the element type, and often even the best name doesn't give quite enough info.

Strife, thanks for the facts, as always!

Jesse, what's trivial to you is not trivial to most. It's as simple as that.

Never said it was trivial. What I have said repeatedly that it is wrong to tell someone that they can not do something even though they can read it just fine. Look back through the thread because this is what you keep saying.

For the last time; If something is readable to you then it is readable. This has been my point all along. The OP asked what was the most efficient way of doing something. All Kaluura did was point out that it is more efficient to use ~ instead of == -! and everyone has jumped in to say how horrible that it is to even make such a suggestion. BS!

Thanks again for the further replies ..

I too tend to mold my coding conventions depending on a myriad of things .. including at times the lack or excess of caffine.

One comment I would have to refut ... that if using a variable or inline for TRUE or FALSE

From the wiki:



So to declare a global integer C_TRUE = TRUE costs 16 bytes, and if you reference TRUE at least three times in your code you have saved space ...

....

Additionally to the comments on 'optimmize algorithms not code' ... agreed .. but there comes a moment when you need to do the former as well.

I'll update it! No need to wait for the hedgie..

(sorry for the OT, folks)

While that is true, it is often easier to think and recognize functionality in logical terms rather than mathematical ones.



OK, which is more readable:

if (x != 7)

or

if (~(x - )

I mean, if doing arithmetic isn't that hard, either one of those should be just as easy to follow, right?

Now, tell me the truth; how much time did you spend checking to see if the second example was correct versus the first one?

Not everyone should HAVE to know at-a-glance what 0 and -1 invert to (and, in fact, not as many as you might think can give an instant and correct answer). Yes, they should be able to work it out in their heads, but that's my point; if there is syntax which you don't HAVE to force someone (including yourself!) to spend time working it out in your head, but can instead glean it (correctly) from a glance, then why not use it, unless there are better reasons not to?

For many folks who have been trained to understand Booleans and how they are supposed to be represented, the second syntax is nonsensical, even though it works (in THIS case). In some situations and implementations, depending on the any_integer != 0 being TRUE will cause all kinds of havoc, and is why it is generally discouraged. There are compilers which use the sign flag as the true/false indicator.. negative numbers are false, positive numbers (and 0) are true. Thus, depending on integer Boolean syntax will make for some late nights (and yes, I have been there).

On a side note, the memory usage page on the lslwiki.net page and what have you are not valid for Mono.

Data not stored in lists takes up the expected amount of space in Mono, as near as I can tell. 4 bytes for integers and floats, etc.

Lists make things.. funky. Especially when you add vectors or rotations to the list. I don't really understand what llGetFreeMemory reports at a given time in Mono or how much memory some Mono operations and data types actually use, but it seems for the most part to be more efficient just in terms of storage.

Sigh................
If your brain can not handle doing something, can not process it, or can not easily read it then no one is saying that you have to do it. This is the crux of the debate. When it comes to efficiency and readabilty and coding in general, someone will state a way they do it, something they find efficient and they can read. No one has EVER said that everyone else has to do it this way. But every single time, no matter who made the suggestion, old or new, novice or even Strife, there are a group of hardcore coders who will plant their feet firmly on the ground and say "NO! YOU CAN NOT DO IT THIS WAY!"

I do care about how others code, I love to see other perspectives and I am sure that there are many more that care also. But I will be damned if I will sit quitely on the sidelines when a group pops up and starts dictating to everyone else here on the forum how they HAVE to start coding. If the words efficiency or optimizations just really grate on your nerves, then please, just for once, ignore the thread and let us have a free exchange of information without the BS.

Reread my post, Jesse. I said "I use ...". And I gave a suggestion that is very defendable:

Optimize algorithms, not code, and learn when that rule doesn't apply

I stand by both those statements. But evidently I touched a nerve.

Concerning you statement that what's readable to YOU is readable to YOU, we're in 100% agreement, when you're the primary reader of the code.

There have been so many optimization threads that have broken down into slugfests with always the same arguments. I did say I had a good memory and this reference thread was kind of mild compared to many, many more but it does have one interesting statement:

/54/5b/217023/1.html



That was from 10/18/07

as said, if it`s readable for you then it`s readable
if your releasing it at a later stage, then it`s still readable

some of the readable codes made public by good programmers are not readable for a nub, last time i had to reread a chunk several times with a wiki on another tab to figure out what was going on (and in this example didn`t even know the tilde trick )

if some one has bad comments about the coding style after you`ve made something public, don`t take any notice of it as you can say you`ve tried

Different people adhear to different notation styles and follow different conventions, depending on their schooling and programming background, I personally find things like if(~lllistfindlist(......) to be perfectly logical as I come from a microprocessor / MacroAssembler background and have had no formal training in programming. In fact due to that I also tend to keep variable and finction names to 3 charecters too
Also bare in mind that the majority of scripters in SL, particularly the ones asking questions in this list, have no formal programming training anyway, so your Hungarian notation may be the only way for you, the antique way for others and as criptic as my TLA approche to new scripters. (TLA = Three Letter Acronym)
To me it depends on what I am trying to achive, if i want to teach I expand all functions and hang the memory or speed cost of the code, if I need it to be efficiant but readable I will use shortcuts but comment them, if I just intend the code to be used but there is no need for the user to understand how it works, I write it as if it were assembler code, optimised, compact and probably unreadable, but document the exposed function calls that the the user needs to interact with, and if its a quick piece of code to be embedded in another script, in answerer to a question, it is as I use it, on the assumption that the person knows what it does as they asked for a specific function, and it is compact as that is how I write code normally.
The attitude on this forum of critisising peoples code style has provented me form posting more than one complex script that many may have benefited from. I once heard the expression, "if it was hard to write it should be hard to read", although I don't subscribe to that view, I do appreciate the sentiment, and if I can use the code without actually having to modify it, then I don't really care what style it is coded in.

Well, I cannot really say, several thoughts went through my mind all at once.
A) yummy obfuscations
B) why would anyone write it that way? (you don't need ~, you could write it as "if(7 - x)"
C) they both are true for the same values
D) I would have used "if(x ^ 7)" instead of either (save a byte in LSO)

But then I enjoy pulling apart clever code obfuscation and I'm in peak form for dealing with it.

Other languages and platforms handle conditionals differently, LSL is no different. A user's expectation that it should behave exactly like any other specific implementation is unreasonable. To help dispel these false assumptions conditionals are documented on the wiki.

Your statement about compilers suggests that some compilers implement booleans differently within the language. Many languages are quite explicit about how booleans are to be implemented, C for example defines both what is considered true by conditionals (6.8.4.1 p2) and what values the comparison and equality operators should return (6.5.8 p6, 6.5.9 p3). Any language that does not specify these technical aspects risks interoperability.

That's the rub as far as I am concerned. You may think, "Ah, only I will ever look at this, and even if I stop programming for a while and get a little out of practice and maybe even senile, I'll always remember what was going through my mind at this point in time," or, "This isn't going to be a final solution; shortly I'll rewrite this completely and scrap the old code," but it is often incredibly surprising how far the most unexpected code can go. I've written little test applications and years later run into my code being used in the heart of production chip test software. I've written a little concept piece for a friend and later run into it being used by nearly everyone I know. It happens.

So I find it useful to write not just to the "expected" audience, but to the general programming/scripting audience. With each bit of code, expect to leave it for three years and come back to see what you were thinking when you wrote it. Expect a fresh beginner just learning the ropes to take what you have written and try to understand it. Expect you or someone unfamiliar with the code to rush through it someday looking for a defect, and not be paying attention to the nuances of every expression.

No, I'm not saying YOU MUST DO IT THIS WAY. Rather, take it as a plea by someone who is going to have to someday look through your code and fix something, enhance it, or or explain to someone new what it is doing. And remember that those habits you form are sometimes difficult to change or even make yourself think about when you come to a place like this forum and post something that's supposed to help others, and help them form their own skills and habits as programmers.

Some relevant quotes:

"If you do not consciously form good habits, you will unconsciously form bad ones." --Unknown

"Form good habits, they are as hard to break as bad ones." --Unknown

"We are what we repeatedly do. Excellence, then, is not an act, but a habit." --Aristotle

oh very true, but i`m looking at this from a nubsters position

i try to keep it clean so i know myself wth i wrote back then and how it worked, but as a self tought(sp) scripter, i just try my best
if some day the larger scripts i`ve made become public and people have comments regarding style, i`ll just say that i`ve tried at the time to the best of my abilities, nothing more and nothing less

over time you learn to adopt some sort of style and compact code that becomes easier to read as you advance but that is all expirience

some times i see a code snippet i wrote 1.5 year ago and my mind boggles as of how inefficient and badly written it is and suprised it actually worked (and still works without crashing the sim!)


edit: not only with lsl, rebuilding the site backend, when created in the first place i`ve just hammerd on getting it finished in a single file using switch cases

now that i`m actually thinking to integrate everything and use shared classes where ever possible for easier access, it`s like writing it completly from scratch, half the code tehre aswell goes "how the hell did i managed to get that working like this???" and ofcourse here and there a lost/redundent function

yeah a lot of my early code was like that... My first script (it still works!) needs to be seriously gutted and entirely reworked, the logic is twisted. At the time I though LSL was a text interpreted language (as opposed to a bytecode interpreted language). Consequently the code is spares on comments, whitespace, nice variable names and has excessive code reuse. I cringe at how badly it was written.

The first platform I took to seriously writing code for was a calculator with limited memory. The language was total crap (it didn't support functions, it only had conditionals and GOTO), and to make matters worse it leaked memory. So I learned to write optimized spaghetti code.

The thing is, good programing practices aren't just about readability, they are also are about acting appropriately. In LSL readability can actually be a liability, depending upon the techniques you use, it can be detrimental to program execution. It's all about balance.

HP, TI, or Casio/Sharp (the later used basic IIRC) ?
I started on the HP's and still prefer Reverse Polish Notation, even in the scripts I write, and my internal scripting language is based on RPF from the HP41 era , progressed to Microprocessors then PC's, but as a hardware person, I did more Algorithmic work and testing than actual coding, especially on the high level languages.

You seem to be of the mindset that someone saying "this is a good way to think about it or do it" or even "this is potentially a better way, because.." automatically equates "YOU CANNOT DO IT ANY OTHER WAY!".

If you've ever worked on a team with others, there are almost always strict coding conventions, where it is actually more like "YOU MUST ADHERE TO THESE!", because everyone is working within the same set of rules and assumptions, and it REDUCES development effort across the team for the project, a net positive for the "good guys".

If you are doing it by yourself, and you are the ONLY ONE who will ever look at your code, then it doesn't matter much what you do (though, through 30 years of programming experience, I can tell you as a matter of that experience that there are many times I have gone back to code I wrote in the past, sometimes DECADES ago, and had to spend a lot of unnecessary time "decoding" what I was doing and why I did it to fix a particularly nasty regression bug in a project based on that code, all because I didn't use the best coding practices I could at the time). Time is our most valuable resource, and while it is completely at our own option to use it wisely or squander it, I don't see the harm in presenting points of view which have known tangible benefits towards saving time (and promoting understanding), if someone is desirous of such.

As for code you publish for others to use, if you do it for a fee, it better be very close to the absolute best you can muster. If you are giving it away, then it's your call, but I would be more inclined to use or recommend code I can easily read and understand without wasting TIME "thinking about it", than code which was heavily optimized for no particular reason.



Except that no one is saying that. That's your own fabrication, I think. The only thing being offered that I have seen is suggestions based on experience, professional or otherwise. The discussion about optimization and efficiency has a valid counterbalance in terms of readability. It's not just here, but industry-wide. This discussion IS the free exchange of information, and for many of us, it is NOT "BS".

You'll note that nowhere has anyone else asked or suggested to silence other points of view, so I have no idea why you are trying to; well, I have an idea, but I will try not to give it much credence, because I don't care much for where it leads. :-/

A) Yes, it was intended as an example, probably a poor one, but some folks have actually done things like that, sometimes to be cute, but once in a while, that is what a serious programmer did, thinking it was the best and most efficient way to do it.
B) Like I said, it was an example, but you make my point, even in your optimized version, because my first impression is "Is there something missing in this code?" and I have to start deconstructing it my mind, wasting my valuable time. Usually, once I have gone to that kind of trouble, I replace the offending code with what I consider is its proper equivalent so I don't (or someone else doesn't) have to waste time in the future, and continue on.
C) Exactly, so if you expect to publish the code for anyone else to read and/or support, why not make their task easier? It probably won't ever matter to you if you are the only one whose eyes ever grace it but, I can tell you from experience that It Just Ain't So.
D) Which, unless there was a significant and/or necessary savings in memory or speed, is not better than the savings in time for anyone else having to understand/maintain it later. In my mind, anyway, human time >>> memory/computer time.



That's true. You like code puzzles. You do well at them. However, I daresay most people who are in the mainstream don't have time for them, and when that deadline looms large, cute obfuscated code puzzles are expensive for the time required, if not downright hated by your coworkers.

I think you've done a lot of cool stuff with your optimizations in LSL; this isn't meant to be an indictment of them in the least. However, if I have to comprehend and support your code, I generally do de-obfuscate it and put it into a more readable format, unless the optimizations are of the kind required for proper operation or necessary efficiency. Then, I just leave them alone and treat them as black boxes (though that is very rare; my mind hates black boxes ).

At the end of the day, that's what it boils down to for me: necessary efficiency at the cost of readability, or readability at the cost of unnecessary efficiency.



I don't agree with that. Certainly, to master any language, you must also master all of its quirks and nuances. However, I would say that better computer languages allow you to express the more abstract concepts of algorithms without having to resort to quirks and nuances. Not just better languages, but also better implementations of certain languages. In any language, colloquialisms are an impediment to understanding and timely communication; they are no less so in a computer language, either. This concept is especially true in terms of the "learning curve" of a language, and if you are writing code which is, in any way, intended to be instructive or helpful to neophytes, you are not doing them any favors by choosing obfuscation over readability.

I mean, what is the point of a computer language anyway? It simply just isn't for providing a method of telling the computer what to do, it is what any language, natural or artificial, is primarily for... communication. In fact, I daresay that computer languages have to pull double duty, not only to communicate to the computer what you want it to do, but to also communicate to other people what you are trying to do. To take this to the most absurd level, why use a human readable computer language at all? If the goal is to make the most efficient, speediest program possible, hand-tuned machine code is the way to go. There are no intervening assumptions or high-level abstractions to get in the way of you telling the computer EXACTLY what you want it to do. It is the ultimate puzzle (and, yes, I have done it, from flipping Address/Data/Step/Load/Store/Run/Stop/Reset switches on the front of Altair and IMSAI 8080A-based systems, to hand-optimizing COMPASS output for CDC Cyber series mainframes), and can be quite entertaining, but the amount of time expended for the benefit, at least nowadays, just doesn't scale.



Correct, within the language model, Booleans are interpreted and handled separately from all other data types. In Pascal, for example, Booleans are their own separate data type, and the language syntax enforces Boolean usage in conditionals. IE, this won't work:

If X - 7 Then Do_Blah;

Because the language expects, as the final result of the conditional expression, a value of Boolean type. Conditional operations result in Boolean values, you can specify Boolean-typed variables or functions, and string together multiple Boolean expressions with the logical AND / OR / NOT operators. It is only really in C and similar languages where non-Boolean expressions can be treated as Booleans by virtue of a value-equivalence quirk which can be non-portable, not only to other implementations of the language, but to other languages in general.

Non-portability when it comes to high-level language constructs is another form of that "quirkiness" or colloquial aspect of the language, which is not something to be cherished, but to be avoided, because it simply acts as an impediment to understanding and, ultimately, wastes human time. In some cases, it is important for it to exist, and in those cases, it can at least be accepted as a necessary evil. However, in the balance of cases, it is just problematic.

Just as a parting analogy, I don't think anyone can argue with the concept of using the right tool for the job. While you can use a screwdriver as a chisel, and it will be serviceable in some cases, if you hand someone a screwdriver and a block of wood, and tell them to carve a duck, they will invariably spend time figuring out how to properly apply the tool to the job, whereas if you had handed them a wood chisel instead, they would be done already.

Simple you are trying to define what is readable for everyone. I have clearly stated umpteen jillion times that if you can read something then it is readable for you. Yet you and others keep stating that "No, you are mistaken. It is not readable" which is ludicrous. It does not matter if it isn't readable to you.

And as far the last line and barb; Yes I do still remember when you were trying to dictate exactly how Void had to present his help here to the others in this very forum. Once again, when you do not have a defensible position, you attack the integrity of the other person, instead of letting the merits of your argument stand on it's own.

reducing the debate to a couple of simple facts

all these memory tricks, constructs, tricks, advanced math stuff or what ever else..
this is great if your a production firm or a dedicated group with skilled programmers, the thing you forget here is that most of the people coming to this forum are anything but skilled programmers

if some one would post a script they made that is decently readable for the general population, no one can tell him his code, put bluntly, sucks

same otherwise, if a skilled programmer would post a script with all available tricks to make it compact as possible with the minimum memory, who do you think you`d please?

hardly anyone cause the general users can`t make heads or tails from it and move on...


seen some pretty neat code snippets on the wiki and here, especially strife`s, thing is, it`s so well written then you go "ehhh...ok, what ever, anything else available in nub language?"
this is how i went most of my learning time and mostly learned from other hobbyists scripts as they were readable

this entire debate is pretty much pointless, from both sides, you can read what hobbyists write but we can`t make heads or tails of what you write

best example,
integer DEBUG = TRUE; // TRUE FALSE
if (DEBUG) do bla;

you know what it means, i know what it means and every new scripter would figure it out in 10 minutes with a simple script what (DEBUG) means
using ~ ^ or what ever other trick and people will have to google to figure out what it does, if they`re bad at it, not find anything and ask here as it isn`t readable or understandable for the general scripter wich just wants to tint their window

there simply is no standard unless agreed on within a group
personally, i`d never adopt some one else`s style if it gives an headache trying to code like that

if (moot) {
bla;
}

if (moot)
{
bla;
}

that lil change alone took me a year to see why SOME people do it like this, easier to spot the if statements and usually still use the first way for if`s in if`s to seperate them and not endup with 100 extra lines to sort trough, if some one that codes would see that, i`d bet he`d shoot me, but it`s readable for me to spot nested if`s in an instant

i`ll stick with if (!)

Yes, and the converse of that assumption is also true. Just because you can read something doesn't mean it is readable for anyone else. Can you at least stipulate to that truism? No one here is saying that they shouldn't do something for themselves, only if they care about doing it for others. If they don't (and I am aware that you don't), then fine, do whatever you want. No one here is saying otherwise.

If everyone only ever saw their own code, and never had to see, use, or work with anyone else's code in the rest of the universe, then what you say might be true.



I think you need to eat some of your own dogfood. I said nothing about your integrity. I said I don't want to go where you seem to want to go IN TERMS OF THE ARGUMENT and tell everyone else their opinion isn't valid and to shut up. You see, it is that last part which is odious, I noted that you are the only one here using it, and I said I didn't want to go there. Period. However, since you can't help yourself...

As for what I said in the past, I still stand behind it, and I think it was quite well-defended. CORRECT examples are better than INCORRECT ones. But, please do go ahead and tell me how wrong I am and to shut up, since that seems to be your response du jour today. At least I am ENcouraging discussion, as opposed to DIScouraging it.

I don't personally see that as a reason not to try. I realize that other people don't agree with that stance, though.



No, but no one should be afraid (or be told to shut up) over making suggestions for improvement, either.



This actually happens a lot with the LibraryWarpPos script. I get IMs all the time with people asking how it works, IF it works, or WHAT it does. It is HEAVILY optimized, and few people can make heads or tails of it. It was INTENTIONALLY optimized to be used as a "black box", keeping the memory footprint down as low as possible for the maximum teleport distance. I would NEVER EVER recommend it for learning, unless someone specifically wanted to learn code optimization techniques. However, I have spent time in IM explaining how it works to folks who are so inclined. I probably need to upload the version I use to reabsorb it every time I come back after 6 months and decipher it.



The whole point of the forum is to help and give advice. The better the advice, the more someone can learn and apply. In the case of this thread, giving "when to optimize" tips is a valid and positive addition to offering optimization tips.

As such, I don't find it pointless at all (well, the ad hominem we could have done without). I would point out something that Jesse has also said in the past which is very relevant (paraphrased, because I can't find the original post): "There are a lot of talented people here giving help, and I think that all the different points of view help everyone immensely".



Oh, definitely. I don't think this is so much a style argument, though, as there is a significant "best practices" element, which is taught in many beginning computer science classes, and for good reason.

Sharing this info and the reasons behind it is a positive thing, I think. Not everyone agrees, though, and that's fine, but last I checked, we're entitled to express our opinions and supporting arguments here.