C# for statement and arrays...

The Asgard said:
Or use the right tools for the right job and do it right first :D
Click to expand...
Still waiting on your explanation. Repeating sound bytes into a leaner thread is so cliché of someone who knows just enough to be dangerous.

Also, "doing it right first time" is the biggest over simplification ever made in the realm of development, and not just software. You really aren't a director, are you? Else you'd already know this.
 
We've completely left the scope of the thread, but I think the idea is if you used Lists and then found performance problems you'd have to write the code again, whereas if you started with an array you wouldn't need to take that time.

Generally speaking, this comes under "technical debt" which the world and his dog are talking about at the moment.
 
Goldy said:
Code: 
//step5 - remove every 7th number after 7
            for (i = 14; i <= listLength; i = i + 7)
            {
                numList.Remove(i);
                //Console.WriteLine(i);
            }

There are several steps that remove certain numbers from the list, that eventually will leave just the prime numbers. Is it possible to collapse chunks of code to make it more manageable? I can imaging things getting very messy if I had to do something which needed more content.

Btw, it was just taking a while to crunch the numbers.
Click to expand...

At the risk of going back on topic and answering the OPs question...

It looks like you're removing all the multiples of prime numbers from your list, but from the code above you appear to be hard coding what the prime numbers are so you'll only ever cope with a set number of them.

In a proper application of the Sieve of Eratosthenes you should simply remove all multiples of the next number in the list that hasn't been already removed. This is guaranteed not to be a multiple of any of the numbers already gone before and so will be the next available prime.

We actually had this in last year's coding competition on here and my solution appears to still be online.
Take a look here for how I did it: http://jcsecurity.co.uk/ocuk/viewer.php?file=haircut_PrimeSieve.cs&lang=csharp

It's not the most elegant code in the world, but it does what I explain above.

It also uses both Arrays and Lists to keep everyone happy :p
 
I have to agree with ASGard on this one.
I have no idea why BUT in tests, in my program, I have observed that Arrays are faster.
However, where lists come into their own is when adding elements one by one. So much easier. No resizing/redim'ing.

I prefer working with lists over Arrays, any day of the week, but in practise, on my program at least, lists are slower.

For a beginner though, Lists are much easier to code.

DJ, if you look at the percentages in that article, you will notice the performance benefits are significant (don't look at the absolute numbers, look at the percentage improvement of array, over List):

http://www.codeproject.com/KB/cs/GenericListVSArray/benchmarkres.png

Ultimately, it depends on just how much performance you are looking to gain and if you are comfortable working with Arrays (instead of List). Like I said, I prefer working with Lists, so I use them most of the time, instead of Array.

I also find that when an array does a redim/resize, there is a MASSIVE performance hit...and I mean MASSIVE.
 
I've already said I agree arrays are faster. :) I've also already said I don't agree with adding complexity to a program, especially for that of a beginner, when it isn't necessary.

I've also already posted what the actual overhead is for a list, and deliberately waited to see if anyone could point it out.. of which nobody did. :p

I'll say it again: What is it with stereo-type developers that have to complicate stuff? :confused:

8ms faster than 0.5 seconds, for 100,000 elements is not significant to the OPs needs tbh :)
 
Last edited:
Dj_Jestar said:
I've already said I agree arrays are faster. :) I've also already said I don't agree with adding complexity to a program, especially for that of a beginner, when it isn't necessary.
Click to expand...

I think that should go for even an advanced programmer: no point in overcomplicating something which could lead to an error (if missed, due to the overcomplicated coding).

Here's an anecdote of my experience with an Array:
A while back I switched from Array, to List.
With the Array, I was using the Redim statement every-time there was an addition to the Array. The array consisted of over 110,000 words loaded from a text file, each word loaded and added to the list, one by one. The first time I ever ran this, the whole process took over 4 minutes. I then switched to multi threading and brought the time down to less than 50 seconds. The final change was moving to lists (where each element was added, using ".ADD(...)". This brought the load time down to 2 seconds!

What I found (rightly or wrongly), was that the Redim statement (I was using VB.NET, at the time), was killing the performance. Apparently, Redim creates a completely new Array (with the specified size, in the Redim statement). It then copies the existing Array, to the new array. Every-time you use Redim, a new Array is created. Do this 110k+ times, with Arrays of size (100K+) and you can understand why it took so long.

Had I used Lists from the get go, I would never have had this performance problem and saved a lot of time. For beginners, Lists are definitely easier to manage.

Anyway, I think we are digressing and I doubt that OP even cares what we are talking about now....I'm out!
 
Having worked on a web site that has tens of thousands of hits per day, most of our performance problems came from people trying to write code that was too focused on performance than maintainability.

Arrays are faster than lists.
For is faster than foreach.
etc

But for you to notice the performance differences you need to be writing code that’s going to get hammered; 99 times out of 100... Aim for maintainability.
 
"Premature optimisation is the root of all evil."
Only start making code perform faster and what not after you get a problem in performance... try and make it readable and more importantly work first. Anyway keep going Goldy, you'll slowly understand it all soon enough! :D
 
sunama said:
I think that should go for even an advanced programmer: no point in overcomplicating something which could lead to an error (if missed, due to the overcomplicated coding).

Here's an anecdote of my experience with an Array:
A while back I switched from Array, to List.
With the Array, I was using the Redim statement every-time there was an addition to the Array. The array consisted of over 110,000 words loaded from a text file, each word loaded and added to the list, one by one. The first time I ever ran this, the whole process took over 4 minutes. I then switched to multi threading and brought the time down to less than 50 seconds. The final change was moving to lists (where each element was added, using ".ADD(...)". This brought the load time down to 2 seconds!

What I found (rightly or wrongly), was that the Redim statement (I was using VB.NET, at the time), was killing the performance. Apparently, Redim creates a completely new Array (with the specified size, in the Redim statement). It then copies the existing Array, to the new array. Every-time you use Redim, a new Array is created. Do this 110k+ times, with Arrays of size (100K+) and you can understand why it took so long.

Had I used Lists from the get go, I would never have had this performance problem and saved a lot of time. For beginners, Lists are definitely easier to manage.

Anyway, I think we are digressing and I doubt that OP even cares what we are talking about now....I'm out!
Click to expand...

This is probably more due to the fact you didn't understand what actually happens when you redim an array rather than lists performing better than arrays. I'd bet that the reason it was so much quicker when you used a list is because the way they implemented resizing lists (haven't checked but probably does something like doubling the size when full but anything that reduces the number of times it has to create a new array would work - which you also could've implemented yourself with the array method) was simply much more economical (in terms of creating new arrays and copying data across) than the way you implemented resizing your array in this case.

That's probably one of those things you do the first time and quickly learn from though :)
 
You must log in or register to reply here.
Back
Top Bottom