Community Experience With Iterators vs Overwriting

  • Thread starter Thread starter jehugaleahsa
  • Start date Start date
J

jehugaleahsa

Hello:

I was running some tests today and found an interesting result. I have
a large library where half the methods work on IEnumerable<T>
(Iterators similar to LINQ), and another that works on List<T>, using
indices to overwrite values.

I wanted to see which performed better overall (I guessed wrong). What
surprised me what that a well-written Iterator typically ran faster
(usually generating a new IEnumerable<U>) than a similar method that
just overwrites a List<T>.

Does anyone have a good explanation for why this is true? Is it just a
fluke on my part? And what does the community say about using one over
the other? I honestly think there is something beautiful about
Iterators and would like to use them more often than not.

Thanks for your input,
Travis
 
Hello:

I was running some tests today and found an interesting result. I have
a large library where half the methods work on IEnumerable<T>
(Iterators similar to LINQ), and another that works on List<T>, using
indices to overwrite values.
ok.


I wanted to see which performed better overall (I guessed wrong). What
surprised me what that a well-written Iterator typically ran faster
(usually generating a new IEnumerable<U>) than a similar method that
just overwrites a List<T>.
Click to expand...

Good for you.
But what is 'faster'?

Is performance a problem for you?
Does anyone have a good explanation for why this is true?
Click to expand...

I have not.
Is it just a fluke on my part? And what does the community say about using
one over
the other?
Click to expand...

I say use 'foreach' over 'for'.
Not because one is faster or not,
but just to get rid of the
'i <= list.Length' bugs.

Also it looks nicer. Much more readable.
Also with typing foreach and press tab, you can do a iterator very quickly.

With the common snippet over foreach, with the old snippet started with
'var',
I just had to write my own foreach-snippet, 'fe' that skips that first step.
Don't need to tab through 'var' with my snippet. 'var' is just fine for me
=)

I honestly think there is something beautiful about
Iterators and would like to use them more often than not.
Click to expand...

I honsestly also think they are beautiful. May have to do something with
that I actaully have to maintain other peoples code!? =)
The for(init; expression; iter) is HighTech from the -70ies (60ies?). - Move
along folks, there is nothing to see here.. move along...
Thanks for your input,
Click to expand...

Use foreach whenever you can.
And Never, Never and NEVER, do a myList.ForEach(lambda => lambda.whatever
== 'something');

... that is just plain ugly!

foreach is your friend!
Travis
Click to expand...

Happy Coding
- Michael Starberg
 
a well-written Iterator typically ran faster
(usually generating a new IEnumerable<U>) than a similar method that
just overwrites a List<T>.
Click to expand...

Well, you can't update the list while enumerating without breaking the
iterator, so you can't be comparing like scenarios here. Iterators
only read data; but updates are generally more expensive (more things
to check) - so if you are overwriting a list you can't be doing the
same thing in the two scenarios. Or are you editing sub-properties of
the items - i.e. is your code doing:

list = foo;
or
list.Bar = foo;
(there is a big difference).

I have done some performance analysis comparing things like List<T> to
IEnumerable<T>, and the conclusion is that it very much depends on
whether you are doing:

List<Foo> foos = ...
foreach(Foo foo in foos) {...}
vs
List<Foo> foos = ...
IEnumerable<Foo> fooAsEnumerable = foos;
foreach(Foo foo in fooAsEnumerable) {...}

The difference is that in the first case the compiler (and JIT) knows
that List<Foo> is sealed, and can use (and inline to) the List<T> and
List<T>.Enumerator methods directly; in the second example it cannot
assume this, so no JIT is possible and virtcall is used.

This seems the opposite to your findings, and I suspect the reason is
one of comparing apples and oranges. If you can post your tests I'd be
happy to investigate? You also need to be quite sure that you are
benchmarking them in a reasonable way...

However!!! It is *very* rare that the difference between the two would
be a significant bottleneck; so unless you know (from repeatable
profiling) that this is actually a performance issue in your app, I'd
concentrate my effort elsewhere.It als

Marc
 
Back
Top