forum.vdsworld.com

[Serge]

Can someone explain what optimising code means and how it applies to VDS?

I gather that it means that you make the code run as fast as possible using as few resources as possible, but how do you do that with VDS?

And given that CPU's are so fast today, does it really matter whether code is optimised or not?

Serge

[SnarlingSheep]

During and after you write a program, look through it and see if you can do some of the things you are doing, with less code or possibly faster.
I think you should always want to make your programs run as fast and as smoothly as possibly, and there will always be users with slow computers out there.
Having less code makes it easier to edit/update/debug for you anyway

Something I used to do was like:

[PGWARE]

[SnarlingSheep]

Hmm, good to know. I wondered if I'd need to be corrected on that
Anything else you can think of that would help optimise code that we might not be doing?

[Mac]

Hmmmm... Prakash is probably right about a slight speed
difference between the two, but I think it would be hard to
measure. And with several similiar dialog elements, I'd go
for the repeat loop myself.

Also, if the speed on a repeat loop does make a difference,
this is going to be the case any time you use one. And I
certainly don't want to add 100 lines of code (or whatever)
every place I'm using a loop.

I usually go for fewer lines of code...

Cheers, Mac
__________________________________________________________________________________________________________________________

[Tommy]

Just about this specific thing mentioned by Sheep, using @BOTH() instead of multiple IF statements may not always be faster as in:

[Henrik]

Hi !

As far as search algorithms are concerned, any algorithm other than the linear search are very much fasater than the linear search (for instance binary search, mergesort, bubblesort, etc) and this also goes for implementations in VDS.

Also I try to use built in functions instead of doing them myself, like using the @match() function instead of iterating through the list myself to find a perfect match.

Henrik

[moke]

Although I am generally amazed that I can even get code work (occasionally). I usually shoot for as few lines of code as possible. Fewer lines is not always faster but it will often be faster. In my case the more important issue is editing. Fewer lines of code makes it easier for me to understand and I need all the help I can get.

[Mac]

Tommy brought up a good point about IF/ELSE statements.
It's a good idea to put all functions/commands that have a
common requirement under one IF statement. If there are
several functions/commands in a loop (or whatever), always
start with the broadest range first and work your way down.
This can save a lot of CPU cycles by not checking several
functions separately for the same criteria.

LOL, and I totally agree with moke...

Cheers, Mac

[Mac]

Tommy, are you sure that each procedure in a @both()
function is checked regardless of the condition of the
first one? Either one being false will return null, so why
would it check the second if the first is false? Or is this
just a DELPHI thing...

Cheers, Mac

[Tommy]

VDS first evaluates the functions most inside. For example in:

@BOTH(@EQUAL(1,2),@EQUAL(2,2))

it'll first evaluate @EQUAL(1,2) and @EQUAL(2,2) and only then it will apply @BOTH() to check if both are true. The evaluator must work like this:

@BOTH(@EQUAL(1,2),@EQUAL(2,2))
@BOTH([null],1)
[null]

Tommy

[VDSuser]

If you've ever programmed in other interpreted languages you'll realize that Tommy is correct. Any time a call is made, the language must interpret the call. Therefore, nested IF statements will execute faster because if the first statement returns FALSE, then none of the nested calls will be performed.

Keeping in mind that the key word in this discussion is "Optimize," here are some other tips:

1. Use variables for often-called statements. For example, if your code often calls @PATH() to refer to the same location, use "%p = @PATH()" one time and then use %p instead of repeating the @PATH call. As %p is already in memory, it's returned faster with less overhead on your program.

2. Don't assign one-use strings to variables, as it wastes resources. The statement "@INFO This is a line of information" is more efficient than "%m = This is a line of information | @INFO %m" if you intend to use the statement only once.

3. Recycle variable names. When %m is no longer used in your code, use %m for something else. This releases the previous value from memory. If %m contains a lot of data that will no longer be used, release it with an "%m =" statement.

4. Keep variable names short. Longer names make for larger compiled code and use more memory.

5. Use subroutines instead of repeating blocks of code. Subroutines keep your main section short and are easier to manage.

Back in the days of 640K RAM, 6Mhz processors, 20MB hard disks and 360K floppies, we programmers were forced to find ways to make sleeker code. Capacities may be much larger today but, in coding, economy still makes for better programs.

[Mac]

Thanks Tommy, I shoulda remembered that from the script
interpreters we made...

[Serge]

Thanks to all who replied to my question, i appreciate your thoughts and answers.

Does it matter where you place subroutines? My understanding is that when using subroutines and you call on one, then the program will always start from the start and search for the subroutine being called. If this is the case, then the often called subroutines would be better placed at the top of the program. Is that right?

Serge

[Mac]

I don't think it's gonna make that much difference. You're
not building games like QUAKE etc. where micro-seconds
add up pretty quick.

I usually put subroutines at the end. It makes everything
easier to keep up with (in my opinion anyway...).

Cheers, Mac