> 1. Is there really a difference in this code?
> if mybool = true then -> if mybool then
Might not be faster, but it is less code. And it might be faster.
Certainly CANT be slower. Better to be safe, I say. I didn't bother to
test it out basically.
> if not mybool then -> if mybool = false then // = false is faster than
> not!
This is faster. I tested this.
> 2. I had planned on defining one variable to a line, a practice that
> saves some bugs in C++ and should improve readability. Theo claims
> that
> dim s as string, p as string, q as string
> Should be written as
> dim s, p, q as string
> I would have thought that the compiler would make these lines
> equivalent. In fact writing
Its pure style. No speed is gained. I prefer that way.
> should be equivalent too. There is another tip that suggests I should
> look for unused variables in dim statements and remove them. Doesn't
> the compiler strip these?
Not yet. Currently RB is unoptimised. All variables take up space, and
must be initialised to 0! So if you have
Dim MyArray(2000) as integer
then RB has to create the array, and initialise the whole thing to 0.
If it was unused, thats wasted CPU time.
>3. Don't return 0 / "" / nil / false unless you have to
>
>if whichByte <= memsize then
> if mystring.byte(whichByte) = byteToCompare then
> return 1
> else
> return 0
> end if
>else
> return -1
>end if
>->
>
>if whichByte <= memsize then
> if mystring.byte(whichByte) = byteToCompare then
> return 1
> end if
>else
> return -1
>end if
> This tip seems error prone. I try to follow the one return point rule
> to simplify reading of code. i.e.
That simply saves executable size.
OK, I can see here I should have explained myself a bit more. My format
was very condensed :o) Its a nit-pick. Don't worry about it.
> I would have expected little or no speed/code size difference between
> these three versions.
Might be little, but there will be some. Depends on how important it is
to you, or depends on your coding style. Perhaps you prefer to leave
out the return value.
> 4. I tend to write methods and functions that do one thing. This leads
> to a lot of small pieces of code. Is there much overhead in function
> calls?
I don't get you here. And yes, there is a lot of overhead (relative to
C).
>5. Get objects to deal with themselves
>
>somewin.someeditfield.text = "a"
>somewin.someeditfield2.text = "b"
>somewin.someeditfield3.text = "c"
>somewin.someeditfield4.text = "d"
>
>->
>
>somewin.somemethod
>
>sub somemethod()
>someeditfield.text = "a"
>someeditfield2.text = "b"
>someeditfield3.text = "c"
>someeditfield4.text = "d"
>end sub
>
> Although I use the second style anyways, I'm surprised that there is
> much of a speed/code size difference.
There is a lot of overhead in this case. This case is a real concern,
NOT a nit-pick, if you have a hot loop doing this.
> I guess what I am really asking is what is the current state of the RB
> compiler? Does it dead strip code and variables, constant propagation,
> common sub-expression reuse, etc...
Its unoptimised. Its a compiler for sure, its not an interpreter, but
it is unoptimised.
> Can anyone suggest other sites that I should look at for information
> like this.
> Chris
> PS. Theo I hope you don't take this negatively. I'm just surprised at
> some of the information that you provide.
No problem.
--
This email was probably cleaned with Email Cleaner, by:
Theodore H. Smith - Macintosh Consultant / Contractor.
My website: <www.elfdata.com/>
|