Which coding is better?

The second ways should be faster, as you are reusing results of computation. the processor later would in any case need several cycles to do the calculations, so prefer the 2nd solution.
By the way, you know the mod(ulo) operator in VB?

hmm.. I thought the second way would be faster, I guess variables aren't that bad unless they are overused.

Somewhere memory will be used, even if you don't explicitely declare variables for it. The compiler hides much of the work in this case you should do in most of the cases.

I think 2 nd option will be useful because the system has the oppurtunity of parsing the entire statement. May be first time it will be somewhat slow but from next time on, u can feel the speed of the execution. This is the logic which is effectively used in PreparedStatement in ADO. So, second option is optimum and effective in every way.

CalculatingYourValuesAndThenConcatenatingShortStringsIsMuchFaster,RatherThanCalculatingAndConcateningThemAllAtOnce.. <---- Screw legibility.. pure peformance!!!! LOL.

Also, as you are working with integers, change your division /'s to \'s (backslashes), avoiding a needless call to the math copressor.

Oh.. and by the way.. fully loaded 650mhz screamers now sell for $999 from Gateway.. We in the VB world are doing just fine.. <wink>.

Interesting enough, but did you do average timing (execute your code 1000 times)? For single statements, you will rarely increase performance drastically, but you should not start using dirty code (ask the pro's)

I used VB6 with output to a text control, and i even realized negative times (1 execution), so you certainly have a very, very, very old machine (-:

K=1
-0.248999999999999
-0.239000000000001
K=10
-0.239000000000001
-0.239000000000001
K=100
-0.239000000000001
-0.228999999999999
K=1000
-0.189
-0.158999999999999
K=10000
0.260999999999999
0.532
K=100000
3.778
2.532

wsh2 :  About that legibility thing.  Once my code is pretty much bug free and all what reason do I have to read it easily?

samopal : I oddly enough never would have thought of actually timing it and seeing how long it takes.  Now I can actually see that the second way is always faster.

Corpse:
Never say Never.. in NeverNever Land.. <smile>. The strength of any developer, is in the reusability of their code. Trust me.. there will be a day when you need to go back.. and beg, borrow or steal an archive. When that happens, I think you will find (like I have many times.. <sheesh>).. that half your time is spent scratching your head, swearing, and uttering "Now.. what the hell did I do here"... <lol>. "Genius At Work" signs are expensive, legible and uncluttered code is free.. <smile>.

A word to my fellow VB Novices and Experts.. Wanna have fun?.. Save your first programming work of art!!! 2 years later, go back and read it (if you can).. you will absolutely roar be amazed and most likely roar in glee.. <smile>.

Corpse, Please know, that no offense was intended. It's just that I have programmed, and managed programmers, for way to long.. <adjusting his pocket protector>. Don't think for a second, that I haven't been down the same road.. and with the same verve as yours.. <smile>. I guess its lucky that from all the head scratching I've done, I still have hair.. <lol>.

See ya in two years.. <wink>.

wsh2,

   <LOL!>  Thanks for inviting me to take a look at this!

Guys...

I only have a couple of things to say...

1) MakingYourCodeAbsolutelyUnreadableByDoingStuffLikeThisIsAJoke!
  There is absolutely no correlation between making your source code unreadable like this and having fast executing code.  It just makes the human reading it frustrated.  Once the program is compiled, the machine language instructions are being executed... Not the source code.

2) Document, Document, Document... wsh2 is right. If a piece of code is well documented, and you can read it, it's really easy to clip pieces you've written into new programs.

3) When you are trying to invision which piece of code is faster, "play computer".  I mean, visualize the instructions that are actually being executed.

For example:

    RGB(98, 64, 128)

returns a long integer based on the calculation of 3 arguments.  Just "playing computer", to come up with this long integer takes several steps.  What is it really doing?

     * Jumping to an executable subroutine
     * Allocating an area in memory
     * Doing hex math to put the 98 in the least significant bits of the allocated memory
     * Doing hex math to put the 64 in the next least significant bits of the allocated memory
     * doing the hex math to put the 128 in the most significant bits of the allocated memory
     * returning from the subroutine

In the expression RGB(98, 64, 128), 98 is x62, 64 is x40 and 128 is x80... and when you look at the number that is returned from the function, you get the long number 8405090, which, in hex is (guess what?)

         x804062

By looking at the pseudo-steps we went through to get this number 8405090, I count 6 things to do... therefore, when you do:

      RGB(98, 64, 128) - RGB(98, 64, 128)...

as part of the original code shown, I see 13 things that have to happen... 6 for each RGB function and 1 to subtract the two results.

If instead, you do:

  A = RGB(98, 64, 128)...
  A = A - A...

I only see 8 thing to do... Since the computer is clock based, it does 8 instructions faster than 13...

But then why do 8 things when you can do:

A = 8405090 - 8405090 ....



Ok, I'm getting down off my soapbox now...



Cheers!®©

So did everyone here die or what??  Anybody home?


Cheers!®©

I mean I AM talking to a Corpse, but am I REALLY talking to a corpse?? <G>

you are talking to a corpse..

Corpse?.. <ears perking up>.. Al Gore.. is that You?.. <smile>

I meant to post something the other day but, I had typed it up after chugging a fifth of the all wonderful Southern Comfort.  Anyway, I can see the major difference in speed when it is actually timed (using samopal's code).  It seems odd though that it takes less calculation time to set and use a variable than to just crunch some numbers.

I mean, think about it, it should take a lot less time to do extra division than to access variables and store them.  Of course, it's probably more or less the other functions like Int(), RGB() and everything else that slowed it down.

I think I'm just gonna go straight out C++ from now on, VB is just way too slow.

So you're not going to award the points at all??

hey, I'll award them to whoever wants them.  Someone just needs to post as an answer.

After someone posts as an answer though I'll wait about a day to make sure there are no objections to them getting the points.

First: You can accept a comment as an answer (as far as I know)
Second: Straight coding can be better, if the compiler "sees" the best way, otherwise use C++ to optimize in an ever-harder-way-to-read

Yea, Just pick the best comment and award the points... Give'm a good grade too. ;-)


Cheers!®©

Adjusted points from 50 to 100

I'm not saying that everyone else didn't help too but, this comment got me thinking cause it actually timed how long it took to do out the commands.  I wouldn't have though of doing that on my own..