For Next loop & looping early

  • Thread starter Thread starter Terry Olsen
  • Start date Start date
T

Terry Olsen

How do I loop back to the beginning of a for/next loop before getting to
the end of it? Isn't there an "iterate" command or something like that?

For Each This in That
...code
if This = False Then (start loop over with next This)
...code
Next
 
* Terry Olsen said:
How do I loop back to the beginning of a for/next loop before getting to
the end of it? Isn't there an "iterate" command or something like that?
Click to expand...

Not in VB.NET 2003. You will have to use a label + 'GoTo', or prevent a
block inside the loop from being executed using 'If...Then'. In VB
2005, 'Continue' is available.
 
Terry,

What do I miss?

For Each This in That
if This = True Then
...code
End if
Next

Works like a charm, with the exception when you try to delete a This in that
code.

I hope this helps?

Cor
 
Yeah that works...I just didn't want to put about 50 lines of code inside a
block if statement.
 
Yeah that works...I just didn't want to put about 50 lines of code inside a
block if statement.
Click to expand...

There's nothing wrong with that. I have no problem using GoTo in this case
because VB has always lacked a Continue statement (wait a year!), but I only
use it in cases where I'm in a deeply nested loop and only one convoluted
condition requires me to iterate immediately. Otherwise I kinda feel
dirty....
 
Terry,
50 lines sounds like you need a new method! :-|

I would put the 50 lines in its own method (Sub or Function) then the For
Each can have a simply If that simply calls the method.

Then again I tend to follow OO with smaller objects with smaller methods...

Hope this helps
Jay
 
What's the largest method you have coded? Believe me, I've split up my
program into Mods & Functions & Methods. But it seems as though I'm slowing
it down quite a bit with all the "jumping around". The meat of the program
is a loop. It goes out to about 30 servers (some on 56k and some on 128k so
threading wouldn't help me here), downloads 30-100 log files from each
server (after telling the server to zip them up), then it unzips & parses
all those files to create an html page that displays the data from the logs
in an easily readable format. I tried having a method called
"WriteLineToFile", but having the code inline seems waaaay faster...
 
Terry,
What's the largest method you have coded?
Click to expand...
Does it really matter? Size doesn't really matter here, the point I was
making is that the "length" of your method is really in the second method,
the first method is simply the loop & possibly the if. The second method has
all the code for the loop itself, allowing the second method to use Exit Sub
to go to the top (bottom really) of the loop...
But it seems as though I'm slowing
it down quite a bit with all the "jumping around".
Click to expand...
Define "seems", I would use CLR Profiler or other profiling techniques to
actually time the loop & subroutines to see how will it performs or not
performs.

Remember the 80/20 rule (link below) that is 80% of the execution time of
your program is spent in 20% of your code. I will optimize (worry about
performance) the 20% once that 20% has been identified & proven to be a
performance problem via profiling (CLR Profiler is one profiling tool).
It goes out to about 30 servers (some on 56k and some on 128k)
downloads 30-100 log files from each
server (after telling the server to zip them up), then it unzips & parses
all those files to create an html page that displays the data from the
Click to expand...
logs
Sounds like the ideal candidate for multi-threading!

As I would expect there is a lag connecting to each server, plus a lag
having each server zip its files, then another lag in downloading the files.
If you save the html pages to disk, there would be a lag there.
Multi-threading would allow your processor to work on another request while
its waiting for the lag...

I would define the routine that processed a single server as a subroutine, I
would then use System.Threading.ThreadPool.QueueUserWorkItem to queue each
request, to this subroutine. Where the Request includes a "State" object
with the server to process & other request specific info. This way a couple
of 128K servers will finish for each 56K server

Unless of course you have a single modem that is dialing each server, then I
would single thread the "download" part & consider multi-threading the unzip
& parse part...


For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware/yetOptimization.pdf

Hope this helps
Jay
 
Back
Top